Ervin,
You are touching multiple issues in your latest message. I would like
to dig on the bottom of this one:
On Wed, May 31, 2017 at 08:32:03AM +0200, Ervin Hegedüs wrote:
> And there is an another issue with 3.0.2 (but may be that affects
> another versions too).
>
> The request is similar that I detailed in my first post. The
> "extraParams" value (JSON field) is this:
>
> extraParams {"node":"3","text":"végső fejezet"}
>
> As you can see, this is a UTF8 text, and client sends it as UTF8:
>
> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
> X-Requested-With: XMLHttpRequest
> Accept-Encoding: gzip, deflate
>
> The encoded URI will be:
>
> extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%C5%91%20fejezet%22
>
> The characters "é" and "ő" are two bytes utf8 characters:
> \xC3\xA9 and \xC5\x91.
>
> But in audit log I get:
>
> ModSecurity: Warning. Matched "Operator `ValidadeByteRange' with parameter
> `1-255' against variable `ARGS:extraParams' (Value:
> `{"node":"3","text":"v\xffffffc3\xffffffa9gs\xffffffc5\xffffff91
> fejezet","parentNode":"0","tid":"144 (3 characters omitted)' ) [file
> "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"]
> [line "488"] [id "920270"] [rev "2"] [msg "Invalid character in request
> (null character)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity
> "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag
> "platform-multi"] [tag "attack-protocol"] [tag
> "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [ref
> "o21,1o22,1o25,1o26,1v921,67t:urlDecodeUni"]
I was kind of expecting problems with 920270, but probably not as
deep rooted ones as this. But first, I need to be able to reproduce
this, and I can't.
Here is my curl call taking up your example:
curl 'localhost/index.html' -d
'extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%C5%91%20fejezet%22'
--trace-ascii -
== Info: Trying 127.0.0.1...
== Info: Connected to localhost (127.0.0.1) port 80 (#0)
=> Send header, 153 bytes (0x99)
0000: POST /index.html HTTP/1.1
001b: Host: localhost
002c: User-Agent: curl/7.50.1
0045: Accept: */*
0052: Content-Length: 82
0066: Content-Type: application/x-www-form-urlencoded
0097:
=> Send data, 82 bytes (0x52)
0000: extraParams=%7B%22node%22%3A%223%22%2C%22text%22%3A%22v%C3%A9gs%
0040: C5%91%20fejezet%22
== Info: upload completely sent off: 82 out of 82 bytes
So the payload is exactly as your payload, but the said rule is not
being triggered.
Can you help me out here. Ideally with a curl call that triggers
920270 in the way you described.
Validating the byte range in combination with UTF8 and friends is
something we might have to drop for PL1. We let ASCII 0 stay in the
default install, but maybe it has to go in light of this false positive
which I think is generic to many languages not using the standard latin
ascii set.
Ahoj,
Christian
--
It is not useful for liberty that we abolish it in order to protect it.
--- Wolfgang Thierse, President of the German Parliament
_______________________________________________
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
