[Owasp-modsecurity-core-rule-set] WHY Rule "950109" matches for ARG "passed_id=81" ?

Ryan Barnett RBarnett at trustwave.com
Tue Nov 2 14:22:47 EDT 2010


On 11/2/10 12:14 PM, "Luís Miguel dos Reis Oliveira e Silva"
<luis.silva at axiomasoft.pt> wrote:

>    
> 
>  Hello,
>  
>  I'm sorry to bring this up again, but my questions didn't get an answer, so I
> still thing these rules to be prone to false positives.
>  
>  As a new release of the rules is comming out soon, I though I should bring
> this up for discussion again.
>  
>  Shouldn't rules 950107, 950109 and 950108 be rewriten to be something more
> like this: "\%[0-9a-fA-F]{2}(?![0-9a-fA-F])|\%u[0-9a-fA-F]{4}(?![0-9a-fA-F])"?
> Like they are now, "%1" would match and, unless I missed the point on what the
> rules should do, this would be a false positive, am I right?
>  
>  Thanks and sorry for all the noise.
>  Luís Silva
>  

Hey Luis,
OK, I had to think on this one a bit.  Keep in mind that this is a chained
rule.  The initial regex check is being used to try and determine if there
*might* be some URL encoded data in the request variable.  If there is, then
it will proceed to the @validateUrlEncoding operator check.

The way the regex is writter now, I agree that there can be some false
positives where the data is not actually encoded and thus would generate
errors when the URL encoding operation is run.  On the flip side, we don't
want to miss any encoded data.

I tried out this new regex and it seems to work -

\%([0-9a-zA-Z]{2}|u[0-9a-fA-F]{4})\%

This regex will look for the common encoding format and it also checks for a
trailing % as encoded data normally consists of multiple characters encoded
in sequence.

Please test this out and see if it works for you.  If anyone else can test
it and let me know if it works that would be great too.  After some more
tests, I will update the CRS.

-Ryan


>  Quoting "Luís Silva" <luis.silva at axiomasoft.pt>:
>  
>> Hello,
>> 
>> On Wed, 2010-09-08 at 10:16 -0500, Ryan Barnett wrote:
>> 
>>> On 9/8/10 10:44 AM, "Dirk Caspari" <d.caspari at eurodata.de> wrote:
>>> 
>>>> --411a3f76-B--
>>>> GET /src/read_body.php?mailbox=INBOX&passed_id=81&startMessage=1 HTTP/1.1
>>>> Host: xxx.xxxxxxxx.de
>>>> User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9.2.3)
>>>> Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
>>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>>>> Accept-Language: de-DE,de;q=0.8,de-de;q=0.6,en-us;q=0.4,en;q=0.2
>>>> Accept-Encoding: gzip,deflate
>>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>>> Keep-Alive: 115
>>>> Connection: keep-alive
>>>> Referer:
>>>> 
>>> https://xxx.xxxxxxxxx.de/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage
>>> =1
>>>> &mailbox=INBOX
>>>> Cookie: xxxxx
>>>> 
>>>> 
>>>> --411a3f76-H--
>>>> Message: Pattern match "\%(?!$|\W)|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4}" at
>>>> ARGS:passed_id. [file
>>>> 
>>> "/etc/apache2/modsecurity/rules-enabled/modsecurity_crs_20_protocol_violatio
>>> ns
>>>> .conf"]
>>>> [line "185"] [id "950109"] [rev "2.0.8"] [msg "Multiple URL Encoding
>>>> Detected"] [severity "NOTICE"] [tag "PROTOCOL_VIOLATION/EVASION"]
>>>> Message: Warning. Operator LT matched 20 at TX:inbound_anomaly_score.
>>>> [file
>>>> 
>>> 
"/etc/apache2/modsecurity/rules-enabled/modsecurity_crs_60_correlation.conf">>>
]
>>>> [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 5, SQLi=,
>>>> XSS=): Multiple URL Encoding Detected !
>>>> %{matched_var_name}=%{matched_var} !"]
>>>> 
>>>> Thanks.
>>>>    D I R K
>>>> 
>>>> 
>>>> 
>>> 
>>> Hmm.. Looks like the previous version in SVN was missing the parentheses in
>>> the RegEx.  Use this latest version -
>>> 
>>> http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/base_r
>>> ules/modsecurity_crs_20_protocol_violations.conf?revision=1535
>>> 
>>> 
>> 
>> The regular expression in rules 950107, 950109 and 950108 shouldn't
>> instead be something like "\%[0-9a-fA-F]{2}(?![0-9a-fA-F])|\%
>> u[0-9a-fA-F]{4}(?![0-9a-fA-F])"?
>> The expression provided will still match for example "%1" and, unless I
>> missed the point on what the rules should do, this would be a false
>> positive.
>> 
>>> 
>>> _______________________________________________
>>> Owasp-modsecurity-core-rule-set mailing list
>>> Owasp-modsecurity-core-rule-set at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
>>> 
>> 
>> Thanks,
>> Luís
>> 
>  
>  
>  ----------------------------------------------------------------
>  This message was sent using IMP, the Internet Messaging Program.
>  




More information about the Owasp-modsecurity-core-rule-set mailing list