Shall we change rule 1000 regex's ?

[buixor]

hello,

to limit the amount of false positive on core rule 1000 :

MainRule "rx:select|union|update|delete|insert|table|from|ascii|hex|unhex|drop" "msg:sql keywords" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1000;

Shall we change the regex to something like :

[^\w]*(select|union|update|delete|insert|table|from|ascii|hex|unhex|drop)[^\w]*

It will greatly reduce false positives on words such as "selection" etc. but it might be bypass-prone ?

[C0nw0nk]

If you look here at the types of MySQL exploits found in web apps.
https://www.exploit-db.com/webapps/

Example :

(select+1+from+(select+count(*),+concat((select+(select+concat(

I think there is allot of variations of methods they can use to try and bypass it spacing between words etc.

I also think its a rule that would need testing for the best outcome as a core rule before being changed.

As the original rule currently sits it is blocking very well and users can insert this. BasicRule wl:1000; #Disable rule to disable it on locations / areas of their sites they do not require it.

I am also curious about this rule with libsql enabled.

LibInjectionSql;
CheckRule "$LIBINJECTION_SQL >= 8" BLOCK;

Its not necessary for those who enable libsql?

[jvoisin]

The modified rule 1000 will still match, since ( and + aren't words.

[buixor]

According to debuggex, the rule shall match, \w matches any word character (equal to [a-zA-Z0-9_])

[ghost]

Seems like a great improvement, this rule matches a lot of data usually.
Thanks

[buixor]

Yes, I'm thinking of at least adding the new rule in 0.56, and we'll see later if we can safely remove the "old" one :)

[Annihil]

\b(select|union|update|delete|insert|table|from|ascii|hex|unhex|drop)\b
works better for me,
it matches select+from but not selected+fromage,
which is what we want I think 😃

[jvoisin]

Good old selected fromage <3