Hi,
the encoding is not relevant as all is 7-bit US-ASCII accoding the
specifications
of HTTP. Anything else must be URL-encoded using %HH notation. You don't need to
struggle with any character set.
Consequentially all (most) rules detect non-ASCII and block, as it's considered
harmful according specifications.
Things can be different in multipart POST data.
However, you can build your own rules to handle such characters if you want to
make
more detailed checks based on specific character sets.
God luck
Achim
Am 21.10.2012 10:07, schrieb Iman Vakili:
>
>
> Hi
>
> I have a big problem about how mod_security interpret other encodings like
> iso-8859-1,
> when I'm sending non ASCII characters like characters from other languages
> (e.g my name: ایمان ) when the encoding page is iso-8859-1(Western European,
> which is Firefox default browsing encoding for example) then the data will
> encoded in html and then transfer to the server (e.g myname:
> ایمان), so I thought I can use
> t:htmlentitydecode to handle the problem but when I was checking my name I
> noticed that this transformation function does not work properly, it changes
> my name to { '\xccE'F }. I think if the function develop to change this kind
> of data to Unicode then it will be the best (like the new utf8tounicode
> function)
> There are more problems for example when there is a "windows-1256" encoded
> web application, my name became: %C7%26%231740%3B%E3%C7%E4, in this encoding
> words doesn't match with PCRE, for example we have \w regex in many rules,
> these characters won't match to \w because of PCRE nature (which is ASCII or
> UTF8 base), I recommend to write a transformation function for these
> encodings too,
>
> Thanks and best regards
>
> ~IMAN
_______________________________________________
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
