Cookie bomb - how to protect?

Server NGINX
#1

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 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:
http://forum.nginx.org/read.php?2,246597,246597#msg-246597

#2

On Sun, Jan 19, 2014 at 8:06 AM, mex [email protected] wrote:

very interesting read:
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.

#3

On Sun, Jan 19, 2014 at 8:35 AM, coderman [email protected] 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

a blunt aggregate rather than header or cookie specific constraints.

best regards,

#4

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

#5

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 :slight_smile:

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:
http://forum.nginx.org/read.php?2,246597,246602#msg-246602

#6

On Sun, Jan 19, 2014 at 1:42 PM, mex [email protected] 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,