|
From: Christian V. <cv...@it...> - 2018-06-13 22:57:25
|
Thanks Christian and Robert, Yes by now I’m using: modesec 2.9.0 nginx refactoring nginx version: openresty/1.9.7.4 OWASP_CRS/3.0.0 Until yesterday I was using OWASP_CRS/2.2.9 and everything was perfect and really fast but I want it to try the 3.0 because they are more complete, crs 2.2.9 version has missing many severity tags. I know that modsec 3 with nginx connector is the new thing and we should use it, but by now I can’t and I would like to wait until more people use this new version and read more comments about it. Anyway here there is a part of the debug log with logs associated to this rules (REQUEST-920-PROTOCOL-ENFORCEMENT.conf) https://pastebin.com/wGxHZScq <https://pastebin.com/wGxHZScq> In line Nº 14 catch the POST in REQUEST_LINE "POST /climbersoul/public/buscador HTTP/1.1” And in line Nº 41 catch a GET from against REQUEST_METHOD. The funny thing that there is no GET method in that request. If is related to a bug for the version that I’m using, well there is nothing much to do for me… I have modified this rule to: SecRule REQUEST_LINE "@rx ^(?:GET|HEAD)$” and it works :), but is not a proper way I think… I think I’m gonna exclude this rule globally and test a bit more to see how it works other wise I’m gonna go back to 2.2.9 rules and put the severity manually… Thanks! Chris. > On Jun 13, 2018, at 5:43 PM, Robert Paprocki <rpa...@fe...> wrote: > > 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 <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... <mailto: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/> <https://www.regextester.com/ <https://www.regextester.com/>> or > > https://regex101.com/r/uO1vS2/5 <https://regex101.com/r/uO1vS2/5> <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 <http://www.myapp.com/> Connection: > > keep-alive Content-Length: 146 Cache-Control: max-age=0 Origin: > > https://www.myapp.com <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 <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 <http://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/ <http://www.modsecurity.org/>); OWASP_CRS/3.0.2. <http://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 <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 <http://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 <http://sdm.link/slashdot> > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... <mailto:mod...@li...> > > https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/> > > http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/> > > > -- > https://www.feistyduck.com/training/modsecurity-training-course <https://www.feistyduck.com/training/modsecurity-training-course> > https://www.feistyduck.com/books/modsecurity-handbook/ <https://www.feistyduck.com/books/modsecurity-handbook/> > mailto:chr...@ne... <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 <http://sdm.link/slashdot> > _______________________________________________ > mod-security-users mailing list > mod...@li... <mailto:mod...@li...> > https://lists.sourceforge.net/lists/listinfo/mod-security-users <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/rules/> > http://www.modsecurity.org/projects/commercial/support/ <http://www.modsecurity.org/projects/commercial/support/> > > ------------------------------------------------------------------------------ > 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/ |
