On 3/17/14 10:01 AM, "Piotr Gackiewicz" <p.gackiew...@intertele.pl> wrote:
>On Mon, 17 Mar 2014, Ramy Darwish wrote:
>
>> Hi Piotr,
>>
>> In my experience, you need to use a utf8toUnicode transformation to
>>properly
>> map UTF8 strings to Unicode before the rule processes the input as
>>Unicode,
>> as well as fine-tune the urlDecodeUni transformation to properly
>>normalize
>> Central European Unicode characters.
>>
>> Provide a code point declaration for the urlDecodeUni transformation,
>> in order to properly normalize Unicode strings (in modsecurity.conf)
>> ---------------------------------------------------
>> # With the 1250 code point for Central Europe:
>> SecUnicodeMapFile /etc/modsecurity/unicode.mapping
>> SecUnicodeCodePage 1250
>> ---------------------------------------------------
>>
>> See these resources for more info:
>> http:
>>//blog.spiderlabs.com/2011/06/modsecurity-advanced-topic-of-the-week-unic
>>ode-mapping-support.html
>
>Thanks for the response.
>Unfortunately, both You and Ryan Barnett in:
>> http: //blog.spiderlabs.com/2012/08/waf-normalization-and-i18n.html
>are probably missing the point.
>
>This is not the problem with URI normalization/Best-Fit Mapping. This is a
>problem with UTF8 multibyte characters, put into rule regexp,
>matched with UTF8-unaware PCRE code.
You are correct. These rules were made prior to the UTF8/Unicode mapping
and transformation functions were added to the ModSecurity code. These
regexes in the rules will be updated (in CRS v.3.0.0) to be quote (')
double-quote (") and backtick (`) characters instead. The
SecUnicodeMapFile directive + t:utf8toUnicode.t:urlDecodeUni
transformation functions should then properly handle the data.
-Ryan
_______________________________________________
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
