# Cookie bomb - how to protect? **URL:** \ **Category:** NGINX\ **Created:** [January 19, 2014, 5:07pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601 "2014-01-19T17:07:38Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [January 19, 2014, 5:07pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/1 "2014-01-19T17:07:38Z")
very interesting read: > **[Cookie Bomb or let's break the Internet.](http://homakov.blogspot.com/2014/01/cookie-bomb-or-lets-break-internet.html)** > > TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser will keep sendin... from thze blogpost: "TL;DR I can craft a page “polluting” CDNs, blogging platforms and other major networks with my cookies. Your browser will keep sending those cookies and servers will reject the requests, because Cookie header will be very long. The entire Internet will look down to you. I have no idea if it’s a known trick, but I believe it should be fixed. Severity: depends. I checked only with Chrome. We all know a cookie can only contain 4k of data. How many cookies can I creates? **Many!** What cookies is browser going to send with every request? **All of them!** How do servers usually react if the request is too long? **They don’t respond** " i checked it, and it works, i get the following error back: 400 Bad Request Request Header Or Cookie Too Large my question: is there a generic way to check the size of such headers like cookies etc and to cut them off, or should we live with such malicious intent? regards, mex Posted at Nginx Forum: > **[cookie bomb - how to protect?](https://forum.nginx.org/read.php?2,246597,246597#msg-246597)** > > very interesting read: http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html from thze blogpost: "TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser... ---
**Author:** ![mex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4da419/32.png) [@mex](https://www.ruby-forum.com/u/mex)\ **Post date:** [January 19, 2014, 5:35pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/2 "2014-01-19T17:35:41Z")
On Sun, Jan 19, 2014 at 8:06 AM, mex [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > very interesting read: > [Egor Homakov: Cookie Bomb or let's break the Internet.](http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html) > > … > my question: is there a generic way to check the size of such headers like > cookies etc and to cut them off, or should we live with such malicious intent? no good one size fits all solution that i have found. trade off here and you worsen over there… i have worked on an internal system (not public endpoint, internal to DMZ only) where the request URL, or any one of the individual request header values could approach 32KBytes in size, with a full client or server header reaching 64+KB. we use a custom Nginx build to handle this on the internal proxy tier only, not public. the public endpoints respond with a custom empty json response body for all such 4xx/5xx errors instead of default 400 like above. i’d love to know of more elegant ways to handle this, with header specific handling - especially cookies, if possible… best regards, P.S. off-topic, but i have used this “feature” before to check for content middling proxies between me and endpoints. such headers often resulting in proxy errors or timeouts even when implemented in transparent trying to be inconspicuous mode. ---
**Author:** ![mex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4da419/32.png) [@mex](https://www.ruby-forum.com/u/mex)\ **Post date:** [January 19, 2014, 5:39pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/3 "2014-01-19T17:39:40Z")
On Sun, Jan 19, 2014 at 8:35 AM, coderman [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > … > i’d love to know of more elegant ways to handle this, with header > specific handling - especially cookies, if possible… the less better way to change this is: [http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#large\_client\_header\_buffers](http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers) a blunt aggregate rather than header or cookie specific constraints. best regards, ---
**Author:** ![mex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4da419/32.png) [@mex](https://www.ruby-forum.com/u/mex)\ **Post date:** [January 19, 2014, 5:48pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/4 "2014-01-19T17:48:38Z")
On Sunday 19 January 2014 11:06:58 mex wrote: […] > i checked it, and it works, i get the following error back: > > 400 Bad Request > > Request Header Or Cookie Too Large > > my question: is there a generic way to check the size of such headers like > cookies etc > and to cut them off, or should we live with such malicious intent? […] You can include into this “Request Header Or Cookie Too Large” error page a JS script that will clear cookies. wbr, Valentin V. Bartenev ---
**Author:** ![mex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4da419/32.png) [@mex](https://www.ruby-forum.com/u/mex)\ **Post date:** [January 19, 2014, 10:42pm UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/5 "2014-01-19T22:42:55Z")
hi coderman, icreasing the headerr\_size is not a solution, since i look for a generic solution to circumvent the outcome of those malicious request. a possible way to handle this is a lighweight WAF-solution, lua comes to my mind 🙂 regards, mex p.s. we’re working on a lighweight lua-based waf as addition to naxsi; but this is very early alpha atm, more on this later. Posted at Nginx Forum: > **[Re: cookie bomb - how to protect?](https://forum.nginx.org/read.php?2,246597,246602#msg-246602)** > > very interesting read: http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html from thze blogpost: "TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser... ---
**Author:** ![mex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4da419/32.png) [@mex](https://www.ruby-forum.com/u/mex)\ **Post date:** [January 20, 2014, 1:46am UTC](https://www.ruby-forum.com/t/cookie-bomb-how-to-protect/238601/6 "2014-01-20T01:46:47Z")
On Sun, Jan 19, 2014 at 1:42 PM, mex [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > this is very > early alpha atm, more on this later. excellent! i agree this would be quite useful in general and appropriate for this specific situation. i’m fond of Lua for mysql-proxy, nmap, and other situations which share similar technical demands for extending built in behavior. i would love to know more as you make progress. best regards,