Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Apr 2013 17:58:18 +0200
From: Stefan B├╝hler <>
Subject: browser document.cookie DoS vulnerability


Chromium 25.0.1364.160 (debian testing), Iceweasel/Firefox 19 and
probably many other browsers allow javascript to set broken cookie
values, leading to possible permanent "400 Bad Request" responses. The
broken value might be set by 3rd party libraries.

For example the google analytics code is vulnerable, as it sets cookie
values based on parameters in the referer query string. lighttpd does
not allow control characters in http header values, so any lighttpd
site using google analytics is vulnerable if you can get the user to
follow a link (img tag for example) to that site like this:

Afaik apache doesn't check the cookie values (or perhaps removes the
broken characters). Imho they are responsible for this mess :)

To be clear: the bug is in the browser / javascript implementation:

document.cookie MUST NOT allow cookie values which include certain
control characters. Javascript applications should not use 8-bit

(If browser vendors want to allow broken cookie values to be stored,
they MUST NOT send them to the server; in this case javascript
applications can still read the broken values. But I don't think this
is a good idea.)

The safe character set for HTTP header values is: %x20-7E; %x80-FF is
obsoleted by the current draft.

"A recipient MAY replace any linear white space with a single SP before
interpreting the field value", so horizontal tabs are not "safe" - they
might get converted to a space, but are not forbidden (also multiple
spaces can get replaced by a single one).

I think this could use a CVE.

The problem was reported in our lighttpd bug tracker:

Kind regards,

Testing the bug:

Try one of the listed urls in the ticket (the error should trigger
after a reload). If you have noscript, request policy, referer control
or similar stuff running you are probably safe; to test the bug in this
case you need a Javascript console on a lighttpd site
( for example), and enter:

> document.cookie = "foo=bar\x05test"
Try to reload the page - it should return a 400 Bad Request page now.

> document.cookie = "foo="
And it should work again.

HTTP references:
> message-header = field-name ":" [ field-value ]
> field-name     = token
> field-value    = *( field-content | LWS )
> field-content  = *TEXT | *(token | separators | quoted-string)
> LWS            = [CRLF] 1*( SP | HTAB )
> # TEXT is superset of (token | separators | quoted-string)
> TEXT = LWS | %x21-7E | %x80-FF
> header-field   = field-name ":" OWS field-value BWS
> field-name     = token
> field-value    = *( field-content / obs-fold )
> field-content  = *( HTAB / SP / VCHAR / obs-text )
> obs-fold       = CRLF ( SP / HTAB )
> # obsolete text
> obs-text = %x80-FF

Basic definitions:
> # horizontal tab
> HTAB = %x09
> # space
> SP = %x20
> # visible ASCII
> VCHAR = %x21-7E
> # carriage return + line feed
> CRLF = %0x0D %0x0A

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ