Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work
|
From: Eric W. <mod...@li...> - 2018-04-04 17:56:23
|
On Mon, 2 Apr 2018, Robert Paprocki wrote: > Right, so the reason SecRuleUpdateTargetById wasn't working was because it was listed in the config file before > my rule definition. It's gotta live after.(ref: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/rules/REQUEST-900-EXCLUSION-RULES-BEF > ORE-CRS.conf.example#L43) > So for example, the following works: > > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/Coo.*/" > > Because the Cookie request header matches that regex. Of course, as mentioned above you cannot whitelist specific > cookie in this manner, it would need to be done like so: > > SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer|!REQUEST_HEADERS:Cookie "\b(\d+) ?= > ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \ > "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl > :auditLogParts=+E,log,auditlog,msg:'SQL Injection > Attack',id:1234123413,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny" > > SecRule "REQUEST_COOKIES|!REQUEST_COOKIES:/_gac_UA[\d-]+$/" "\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \ > "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl > :auditLogParts=+E,log,auditlog,msg:'SQL Injection > Attack',id:1234123414,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny" > > But again, using REQUEST_COOKIES as a target is not meaningful because the regex in question doesn't match the > cookie value, only the name+value. Hello Robert and Christian, Thank you for your help figuring this out! This is a default rule from cPanel that tries to match content like "1=1" for SQL injections. Ultimately matching a cookie on an equals sign in the header is a false positive because the header always contains <cookie_name>=<cookie_value>; an application is only ever going to use the cookie name or cookie value independently, but not at it appears in the header (I hope!). To solve this, we have created a rule based on your suggestions that specifically checks this SQL injection attack in cookie names and cookie values independently and excluded cookie processing from the header section to prevent the false positive. This solves the issue for Google cookies and is more correct in terms of addressing this type of attack. These are the new rules: SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie" SecRule REQUEST_COOKIES_NAMES|REQUEST_COOKIES "\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \ "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack',id:'1334123413',tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2'" Thank you again! -- Eric Wheeler > > > > On Mon, Apr 2, 2018 at 2:20 PM, Robert Paprocki <rpa...@fe...> wrote: > Okay, so I got the following to work (as expected), ignoring SecRuleUpdateTargetById which I've never > had much luck with: > SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" > \ > "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl > :auditLogParts=+E,log,auditlog,msg:'SQL Injection > Attack',id:1234123413,tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:'2',deny" > > SecRule ARGS:test "@streq foo" "id:12345,deny,phase:2,msg:'lolnope',sanitiseArg:yomama" > > SecAction "ctl:ruleRemoveTargetById=1234123413;REQUEST_HEADERS:Cookie,id:12346,phase:1" > > Relevent debug logs: > > https://gist.github.com/p0pr0ck5/3d7b38c3c182604242449ff0b04c444d > > @Eric, because your rule targets REQUEST_HEADERS and not COOKIES, you cannot remove a specific cookie from > this target. Headers and cookies are treated as separated tables. You will either need to use an ignore or > craft a second rule that looks specifically at cookies. > > BTW, you may want to evaluate the regex in question here; what specifically are you trying to catch? It > matches on a cookie only because of how cookies are formed. > > On Mon, Apr 2, 2018 at 1:41 PM, Robert Paprocki <rpa...@fe...> wrote: > Hey Christian, > > On Mon, Apr 2, 2018 at 1:38 PM, Christian Folini <chr...@ne...> wrote: > Hello Eric, > > On Mon, Apr 02, 2018 at 07:31:14PM +0000, Eric Wheeler wrote: > > We have tried the following, but none have worked: > > > > SecRuleUpdateTargetById 1234123413 > "!REQUEST_COOKIES_NAMES:/_gac_UA-5521579-1/" > > SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:/_gac_UA-5521579-1/" > > > > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-5521579-1/" > > > > SecRuleUpdateTargetById 1234123413 > "!REQUEST_COOKIES_NAMES:_gac_UA-5521579-1" > > SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521579-1" > > > > > > Interestingly, these two work, but are of course too permissive: > > > > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./" > > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie" > > If > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./" > works, it's undocumented behaviour. This does not really support regexes. > > > From > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRuleUpdateTargetById: > > Note that is is also possible to use regular expressions in the target specification: > > SecRuleUpdateTargetById 981172 "!REQUEST_COOKIES:/^appl1_.*/" > > Interestingly, neither of the following work for me: > > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/./" > SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:Cookie" > > And there is no meaningful log-level 9 debug information to indicate that SecRuleUpdateTargetById did > anything (im still walkingthrough https://github.com/SpiderLabs/ModSecurity/blob/72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L19 > 8 at this point- busy watching the Falcon 9 launch atm ;) ). > > > > > |
