|
From: Robert P. <rpa...@fe...> - 2018-06-13 21:43:53
|
Hey Christian/Christian, It looks like you're using the legacy ModSecurity 2.9x hack with Nginx, based on the 'producer' line and form in your audit logs. This is a big no-no, for a number of reasons :) We would (very) strongly urge you to use the 3.x branch of ModSecurity ( https://github.com/SpiderLabs/ModSecurity-nginx). There could be a number of reasons for this tripping, like Nginx rewriting the request method as part of an internal redirect or some screwy memory/race condition bug, or possibly a problem with the SecRules parser (I've see this a lot in the Nginx 2.x hack), but it's not worth digging into at this point. 2.x ModSecurity on Nginx isn't supported and shouldn't be discussed further :) On Wed, Jun 13, 2018 at 1:37 PM, Christian Folini < chr...@ne...> wrote: > 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= > eyJpdiI6InJ0T1MreDdTcFVHZnJ6eFFVUVJibVE9PSIsInZhbHVlIjoiOWVp > dnlhXC9UY29Cclk3dDhmUUYxSzZ5bGRLMWExVzhuVTNXZUFrSW1LR2hGQnNE > b0kxdXc4XC9lOWE2R1BXcGZtZWR0alJEbHA2R1JhSmpTbXBoSUp6enNMMnRM > NEZFNXpVZytxYmN3c2lRMD0iLCJtYWMiOiI0YTdmMWE4Y2M0Y2E2YjY3MWEy > NTRhZjNkM2RmNDhlMmFiYTExOWVmZmQ2OTYzYjRjOWE3M2Y0M2VlYzljODc1In0%3D; > > XSRF-TOKEN=eyJpdiI6ImxZeDdKWTNuUE53R2RoaDhuTEptRlE9PSIsInZhbHVlIjoiM1RP > d3AzU2F5RjhldmJLQmxwaWR2VFU3Z1Y5dUlTSDRrcmx3dkZ4dDMxekZEUkRn > SVpTcG9wUXJqOHdEbHlTRlJ2V2hVVkRabFZEZ0M1a1JKSmxzOWc9PSIsIm1h > YyI6IjZkMmFkODc3YmY1YWEwYWY2NjQ2YjhlZDEwZmExMDVlY2MyMzE1Y2Ji > NDI5ODcxMTA0OTYxMTdkNWQzODZkMWMifQ%3D%3D; > > > > myapp_session=eyJpdiI6Im5lTHJwWlZqZnpcL1lMWk > JRZ2ZVbW9nPT0iLCJ2YWx1ZSI6IitBOWVtQ0djQzczaGRkMlc3ck1jWXg3Yl > lGVlNFaTZ5NW1EbERDY29ER0w1MWFaR3IzcVArK1hlY2d0SXpzRVBlSWRhZ0 > 1mNUMzRXpkYlNreUpxR0lBPT0iLCJtYWMiOiJmZWEwNzQxZTQwYzI1NmQ5Mz > dmOTI2NGY4Y2UxNjI5ZDFlOGQxNjU5NmJhZDE2YzdiYTg4YzQ5ZWU4ODc3YmY1In0%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 > > ------------------------------------------------------------ > ------------------ > 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/ > |
