|
From: Christian F. <chr...@ne...> - 2018-06-13 20:39:12
|
Hi Christian, Christian here too. You are asking a Core Rule Set question, but the effect you are describing does indeed sound like a ModSec issue, so it seems only legit to pass over the CRS mailinglist and address the ModSec user list. So you have a POST request that matches on a rule with the following constraint? SecRule REQUEST_METHOD "@rx ^(?:GET|HEAD)$" ... That sounds quite unbelievable. - What ModSec version are you running and on what webserver? - Could you raise the debug log level to 9 and give us the full debug log for 920170? That should clear things up or allow us to reproduce this misbehaviour. Thanks for the detailed payload. That's a very good base already. Ahoj, Christian On Wed, Jun 13, 2018 at 03:12:28AM -0400, Christian Varas wrote: > Hi, I’m getting a false positive with a particular rule in crs 3.0.2, the > rule block any request ( GET or HEAD) when the content-length is not a 0 > digit or is empty. > > The problem that rule match any POST request too. I tried same regex > ^(?:GET|HEAD)$ in online tools but it doesn’t work, in sites like: > https://www.regextester.com/ <https://www.regextester.com/> or > https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> only works > if I remove the “$” character, ex: ^(?:GET|HEAD) but if use this regex in > the rule, I’m still getting the false positive… > > I always can exclude this rule, but I would like to fix it. > > Any help would be really appreciated! > > Post: > > POST /myapp/public/buscador HTTP/1.1 Host: www.myapp.com Connection: > keep-alive Content-Length: 146 Cache-Control: max-age=0 Origin: > https://www.myapp.com Upgrade-Insecure-Requests: 1 Content-Type: > application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Macintosh; Intel > Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 > Safari/537.36 Accept: > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 > Referer: https://www.myapp.com/myapp/public/buscador Accept-Encoding: gzip, > deflate, br Accept-Language: en-US,en;q=0.9,es;q=0.8 Cookie: > remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVpdnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNEb0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRMNEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEyNTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D; > XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RPd3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRnSVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1hYyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2JiNDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D; > > myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWkJRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3YllGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ01mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5MzdmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%3D > > Modsec info: > > Message: Access denied with code 403 (phase 2). Match of "rx ^0?$" against > "REQUEST_HEADERS:Content-Length" required. [file > "/opt/waf/nginx/etc/modsec_rules/www.myapp.com/enabled_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] > [line "271"] [id "920170"] [rev "1"] [msg "GET or HEAD Request with Body > Content."] [data "146"] [severity "CRITICAL"] [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/INVALID_HREQ"] [tag "CAPEC-272"] Action: > Intercepted (phase 2) Apache-Handler: IIS Stopwatch: 1528871402000491 498451 > (- - -) Stopwatch2: 1528871402000491 498451; combined=5145, p1=327, p2=4743, > p3=0, p4=0, p5=75, sr=20, sw=0, l=0, gc=0 Producer: ModSecurity for nginx > (STABLE)/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.2. Server: > ModSecurity Standalone Engine-Mode: "ENABLED" > > Rule with issues: > > # Do not accept GET or HEAD requests with bodies > > # -=[ Rule Logic ]=- # This is a chained rule that first checks the Request > Method. If it is a # GET or HEAD method, then it checks for the existence > of a Content-Length # header. If the header exists and its payload is > either not a 0 digit or not # empty, then it will match. # # -=[ References > ]=- # http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3 # SecRule > REQUEST_METHOD "^(?:GET|HEAD)$" \ "msg:'GET or HEAD Request with Body > Content.',\ severity:'CRITICAL',\ id:920170,\ ver:'OWASP_CRS/3.0.0',\ > rev:'1',\ maturity:'9',\ accuracy:'9',\ phase:request,\ block,\ > logdata:'%{matched_var}',\ t:none,\ tag:'application-multi',\ > tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ > tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\ tag:'CAPEC-272',\ chain" > SecRule REQUEST_HEADERS:Content-Length "!^0?$"\ "t:none,\ > setvar:'tx.msg=%{rule.msg}',\ > setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\ > setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}’" > > > Cheers! Chris. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
