Ryan,
the Server and the page uses utf-8 encoding.
When the form is being submitted the apache log looks like this:
"GET /test.php?keywords=%C4%99 HTTP/1.0" 403 375 "-" "Mozilla/5.0 (X11;
Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1"
You can see the "ę" is correctly encoded using utf-8 as "%C4%99". Why is
modsecurity not decoding this in a proper way before doing it's tests?
Or is it an apache configuration problem?
Christian
On 08/23/2012 06:39 PM, Ryan Barnett wrote:
> Christian,
> Is this an application that you control? It looks as though this is some
> type of search field where the user can type in text. If this is the
> case, then I suggest that the application use proper Unicode encoding of
> the input data so that the param field would be - keywords=%u0119 rather
> than keywords=ę.
>
> In addition, I would suggest that you add the following to your
> ModSecurity main config file -
>
> SecUnicodeCodePoint 20127
> SecUnicodeMapFile /path/to/unicode.mapping
>
> You will need to adjust the first directive to suit your local code point.
> 20127 maps to US-ASCII. The unicode.mapping file comes bundled with the
> ModSecurity source code. By using these directives, any t:urlDecodeUni
> transformation functions will map the Unicode data to the mappings you
> specify.
>
> -Ryan
>
>
>
> On 8/23/12 9:34 AM, "Christian Klossek" <c.klos...@apodiscounter.de> wrote:
>
>> Hi,
>>
>> I'm using modsecurity 2.6.7 with CRS 2.2.5 on a debian squeeze system.
>>
>> Why is the rule 981318 triggering on a GET-param with a value of "ę"
>> (Unicode U+0119)?
>>
>> I get this in my debug log (debug level 9):
>> -------------------------------------
>> SecRule
>> "REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XM
>> L:/*"
>> "@rx
>> (^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\x
>> 80\x98;]+$)"
>> "phase:2,nolog,auditlog,rev:2.2.5,capture,t:none,t:urlDecodeUni,block,msg:
>> 'SQL
>> Injection Attack: Common Injection Testing
>> Detected',id:981318,logdata:%{TX.0},severity:2,tag:WEB_ATTACK/SQL_INJECTIO
>> N,tag:WASCTC/WASC-19,tag:OWASP_TOP_10/A1,tag:OWASP_AppSensor/CIE1,tag:PCI/
>> 6.5.2,setvar:tx.msg=%{rule.msg},setvar:tx.sql_injection_score=+%{tx.critic
>> al_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},se
>> tvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
>>
>> Expanded
>> "REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XM
>> L:/*"
>> to "REQUEST_FILENAME|ARGS_NAMES:keywords|ARGS:keywords".
>>
>> T (0) urlDecodeUni: "/test.php"
>> Transformation completed in 13 usec.
>> Executing operator "rx" with param
>> "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\
>> x80\x98;]+$)"
>> against REQUEST_FILENAME.
>> Target value: "/test.php"
>> Operator completed in 9 usec.
>>
>> T (0) urlDecodeUni: "keywords"
>> Transformation completed in 13 usec.
>> Executing operator "rx" with param
>> "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\
>> x80\x98;]+$)"
>> against ARGS_NAMES:keywords.
>> Target value: "keywords"
>> Operator completed in 4 usec.
>>
>> T (0) urlDecodeUni: "\xc4\x99"
>> Transformation completed in 14 usec.
>> Executing operator "rx" with param
>> "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\
>> x80\x98;]+$)"
>> against ARGS:keywords.
>> Target value: "\xc4\x99"
>> Added regex subexpression to TX.0: \x99
>> Added regex subexpression to TX.1: \x99
>> Operator completed in 38 usec.
>> Setting variable: tx.msg=%{rule.msg}
>> Resolved macro %{rule.msg} to: SQL Injection Attack: Common Injection
>> Testing Detected
>> ..
>> ..
>> -------------------------------------------
>>
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
