<div dir="ltr">Thanks Victor,<div><br></div><div>The example response on the wiki page doesn't make it clear that 'Set-Cookie:' also applies here. In fact it includes 'Set-Cookie:' in the http_header, http_raw_header definition.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 1:53 PM, Victor Julien <span dir="ltr"><<a href="mailto:lists@inliniac.net" target="_blank">lists@inliniac.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14-04-16 22:16, Duane Howard wrote:<br>
> According<br>
> to: <a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki/HTTP-keywords" rel="noreferrer" target="_blank">https://redmine.openinfosecfoundation.org/projects/suricata/wiki/HTTP-keywords</a><br>
> """Although cookies are sent in an HTTP header, you can not match on<br>
> them with the http_header keyword. Cookies are matched with their own<br>
> keyword, namely http_cookie."""<br>
><br>
> I had a couple of questions about this:<br>
><br>
</span>>  1. Is this documentation still accurate?<br>
<br>
Yes.<br>
<br>
Note that it also applies to Set-Cookie.<br>
<br>
>  2. Does this mean that Suricata will effectively strip the 'Cookie:<br>
<span class="">>     foo=120398' out from the http_header buffer? Or will it still<br>
>     contain 'Cookie:' for example? [0]<br>
<br>
</span>It is stripped (or actually not included in reconstruction):<br>
<a href="https://github.com/inliniac/suricata/blob/master/src/detect-engine-hhd.c#L165" rel="noreferrer" target="_blank">https://github.com/inliniac/suricata/blob/master/src/detect-engine-hhd.c#L165</a><br>
<br>
>  3. If above is true, is the correct way to perform relative matches of<br>
<span class="">>     'Cookie: foo=12398' to other header fields to use a plain content<br>
>     match, and not the http_header buffer?<br>
<br>
</span>Use http_raw_header. It does include the cookie headers.<br>
<span class=""><br>
><br>
> If my understanding of this is correct I think there's at least one ET<br>
> rules that are probably not working as intended, since I see content<br>
> negations of 'Cookie|3A|'; http_header; as well as Cookie value checks<br>
> against http_header. Example rule from ET Open[1]<br>
><br>
> [0] Does this:<br>
> GET /foo.js HTTP/1.1<br>
</span>> Host: <a href="http://no.evil.com" rel="noreferrer" target="_blank">no.evil.com</a> <<a href="http://no.evil.com" rel="noreferrer" target="_blank">http://no.evil.com</a>><br>
<span class="">> Cookie: UID=17220493a47a2391519d61c144a531063; UIDR=1649534063; CP3=4<br>
> Connection: keep-alive<br>
> Cache-Control: max-age=0<br>
> Accept: */*<br>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,<br>
> like Gecko) Chrome/49.0.2623.110 Safari/537.36<br>
> Referer: <a href="http://www.referme.com" rel="noreferrer" target="_blank">http://www.referme.com</a><br>
> Accept-Encoding: gzip, deflate, sdch<br>
> Accept-Language: en-US,en;q=0.8<br>
><br>
> yield this for http_header?<br>
</span>> Host: <a href="http://no.evil.com" rel="noreferrer" target="_blank">no.evil.com</a> <<a href="http://no.evil.com" rel="noreferrer" target="_blank">http://no.evil.com</a>><br>
<span class="">> Connection: keep-alive<br>
> Cache-Control: max-age=0<br>
> Accept: */*<br>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,<br>
> like Gecko) Chrome/49.0.2623.110 Safari/537.36<br>
> Referer: <a href="http://www.referme.com" rel="noreferrer" target="_blank">http://www.referme.com</a><br>
> Accept-Encoding: gzip, deflate, sdch<br>
> Accept-Language: en-US,en;q=0.8<br>
><br>
> Example of ET Rule that's probably broken:<br>
> [1] alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET<br>
> CURRENT_EVENTS DRIVEBY EgyPack Exploit Kit Cookie Set";<br>
</span>> flow:established,from_server; *content:"Cookie|3a| visited=TRUE";<br>
> http_header;* *content:"Cookie|3a| mutex="; http_header;*<br>
> reference:url,<a href="http://www.kahusecurity.com/2011/new-exploit-kit-egypack/" rel="noreferrer" target="_blank">www.kahusecurity.com/2011/new-exploit-kit-egypack/</a><br>
> <<a href="http://www.kahusecurity.com/2011/new-exploit-kit-egypack/" rel="noreferrer" target="_blank">http://www.kahusecurity.com/2011/new-exploit-kit-egypack/</a>>;<br>
> reference:url,<a href="http://www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack" rel="noreferrer" target="_blank">www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack</a><br>
> <<a href="http://www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack" rel="noreferrer" target="_blank">http://www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack</a>>;<br>
> reference:url,<a href="http://blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/" rel="noreferrer" target="_blank">blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/</a><br>
> <<a href="http://blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/" rel="noreferrer" target="_blank">http://blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/</a>>;<br>
<span class="">> classtype:bad-unknown; sid:2014407; rev:3;)<br>
><br>
<br>
</span>Looks like this is indeed broken.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" rel="noreferrer" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" rel="noreferrer" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
<br>
</font></span></blockquote></div><br></div>