Hello Jens,
Thank you for reporting this. I agree with you, that the operator
parameter in the said rule (bytes=0-) is bogus:
SecRule REQUEST_HEADERS:Range "@beginsWith bytes=0-" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'6',accuracy:'8',\
t:none,block,msg:'Range: field exists and begins with\
0.',logdata:'%{matched_var}',severity:'4',id:'958291',...
However, the msg action seems to support the way it is written
and the comment above the rule starting with paragraph 1 confirms this:
# 1. Range Header exists and begins with 0 - normal browsers don't do this.
# Automated programs and bots often do not obey the HTTP RFC
However, normal browsers do this all the time. Hence the
false positives everybody is seeing on requests downloading big
files.
I usually tune the rule away completely. I guess you are aware that
outcommenting is a bad way of handling a false positive. The preferred
way in this case is probably:
SecRuleRemoveById 958291
Now looking forward, this rule has been removed for the 3.0 release,
so the false positive problem will be gone in the future. It is
unclear if a new release in the 2.2.X range will be released.
Unlikely actually.
Summing it up: Yes, the way the rule is written right now, brings
false positives like mad. It blocks a behaviour the browsers
use. It is a bad rule. It's gone for good.
Cheers,
Christian
P.S. Nice catch on the apache configure script problem on httpd-dev!
On Wed, Jun 29, 2016 at 12:00:56PM +0200, Jens Schleusener wrote:
> after downloading
> SpiderLabs-owasp-modsecurity-crs-2.2.9-30-g520a94b.tar.gz I just
> compared the changed rules with that used on "my" server. One rule
> that I have outcommented but that still exists unchanged is rule
> 958291 in base_rules/modsecurity_crs_20_protocol_violations.conf.
>
> That rule is commented with
>
> # 1. Range Header exists and begins with 0 - normal browsers don't do this.
> # Automated programs and bots often do not obey the HTTP RFC
> #
> # -=[ Rule Logic ]=-
> # This rule inspects the Range request header to see if it starts with 0.
> #
> # -=[ References ]=-
> # http://www.bad-behavior.ioerror.us/documentation/how-it-works/
>
> But that I am not really understanding since at least
> https://tools.ietf.org/html/rfc7233
> seems to allow it:
>
> 2.1. Byte Ranges
> [...]
> Examples of byte-ranges-specifier values:
> o The first 500 bytes (byte offsets 0-499, inclusive):
> bytes=0-499
>
> Maybe a pure "bytes=0-" is meant but the rule seems to match also
> "bytes=0-last-byte-pos".
>
> Additionally the referenced URL
> http://www.bad-behavior.ioerror.us/documentation/how-it-works/
> is not (or no longer) existent.
>
> Regards
>
> Jens
> _______________________________________________
> 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
--
ModSecurity Training in London: Sep 22/23, 2016
https://www.feistyduck.com/training/modsecurity-training-course
mailto:christian.fol...@netnea.com
twitter: @ChrFolini
_______________________________________________
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
