Thread: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

Brought to you by: victorhora, zimmerletw

mod-security-users

[mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Eric W. <mod...@li...> - 2018-04-02 19:43:48

Hello all,

We've been scratching our heads trying to whitelist Google cookies that 
are breaking some sites. The rule we are hitting is:

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'"

This is the cookie:

Cookie: _gac_UA-5521579-1=1.1522352332.EAlalQobChMI5trKIKSS2gIV0IKzCh2vIQeDEAAYASAAEgICPPD_8wE


This is the error that we are getting:

[Mon Apr 02 15:21:20.137112 2018] [:error] [pid 7908:tid 140248145336064] [client 24.20.122.25] ModSecurity: Warning. Pattern match "\\\\b(\\\\d+) ?= ?\\\\1\\\\b|[\\\\'\\"](\\\\w+)[\\\\'\\"] ?= ?[\\\\'\\"]\\\\2\\\\b" at REQUEST_HEADERS:Cookie. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "98"] [id "1234123413"] [msg "SQL Injection Attack"] [data "1=1"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [hostname "example.com"] [uri "/"] [unique_id "WsKCsMYURboAAB7kVSwAAADA"]


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"


We are running ModSecurity 2.9.0 under WHM 58.0.52

Can anyone suggest a way to solve this?

Thank you for your help!

--
Eric Wheeler

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Christian F. <chr...@ne...> - 2018-04-02 20:38:51

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.

However, this is meant to work:
SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521579-1"

Could you please raise your ModSec Debug level to 9 and check what is
going on? You should see this cookied added to an ignore list and then
when 1234123413 is being executed, it should be removed from the list
of targets for the rule.

If it really does not work, you might have to do a runtime rule exclusion
via a ctl statement.

Ahoj,

Christian

-- 
Integrity without knowledge is weak and useless, and knowledge
without integrity is dangerous and dreadful.          
-- Samuel Johnson

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Robert P. <rpa...@fe...> - 2018-04-02 21:08:15

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 walking through
https://github.com/SpiderLabs/ModSecurity/blob/72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198
at this point- busy watching the Falcon 9 launch atm ;) ).

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Christian F. <chr...@ne...> - 2018-04-02 21:20:20

Hey Robert,

On Mon, Apr 02, 2018 at 01:41:30PM -0700, Robert Paprocki wrote:
> 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_.*/"

Now look at that! Glad you checked. I overlooked this after I had made
up my mind based on the handbook and then confirmed this with the link above.

But either way: If it does not work, then it's of no use. ;(

> And there is no meaningful log-level 9 debug information to indicate that
> SecRuleUpdateTargetById did anything (im still walking through
> https://github.com/SpiderLabs/ModSecurity/blob/72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198
> at this point- busy watching the Falcon 9 launch atm ;) ).

SecRuleUpdateTargetById does not report much. But SecRule will.

Ahoj,

Christian


-- 
It is not useful for liberty that we abolish it in order to protect it.
--- Wolfgang Thierse, President of the German Parliament

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Robert P. <rpa...@fe...> - 2018-04-02 21:20:18

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-552
>> 1579-1/"
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-552
>> 1579-1/"
>> >
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_U
>> A-5521579-1"
>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521
>> 579-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 walking through
> https://github.com/SpiderLabs/ModSecurity/blob/
> 72f632e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198 at this point-
> busy watching the Falcon 9 launch atm ;) ).
>

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Robert P. <rpa...@fe...> - 2018-04-02 22:03:52

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-
BEFORE-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.



On Mon, Apr 2, 2018 at 2:20 PM, Robert Paprocki <rpaprocki@
fearnothingproductions.net> 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:'lo
> lnope',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-552
>>> 1579-1/"
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_HEADERS:/_gac_UA-552
>>> 1579-1/"
>>> >
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES_NAMES:_gac_U
>>> A-5521579-1"
>>> >       SecRuleUpdateTargetById 1234123413 "!REQUEST_COOKIES:_gac_UA-5521
>>> 579-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-Man
>> ual-%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 walking through
>> https://github.com/SpiderLabs/ModSecurity/blob/72f63
>> 2e9b6b2e63677cfba7e62a47efb87c90b48/apache2/re.c#L198 at this point-
>> busy watching the Falcon 9 launch atm ;) ).
>>
>
>

Re: [mod-security-users] REQUEST_COOKIES_NAMES:/regex/ does not work

From: Christian F. <chr...@ne...> - 2018-04-03 04:19:07

On Mon, Apr 02, 2018 at 03:03:42PM -0700, 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-
> BEFORE-CRS.conf.example#L43)

Note to self: Don't attend 2-hour CRS community chat and then try to respond
to questions on mailinglist quickly before going to bed.

Christian


-- 
Orwell never meant 1984 as a blueprint!
-- Comment found on Bruce Schneier's blog

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 ;) ).
> 
> 
> 
> 
>