Protecting Your Cookies: HttpOnly

Couple comments about this post:<p>(1) HttpOnly makes cookie harvesting harder, but it does not protect you against cross-site scripting. An attacker that can inject JS into your browser can still force you to perform actions in that application under the cookie. This is a patch to the exploit, not to the vulnerability.<p>(2) As implemented in a bunch of places today, it's just a speed bump: you can read HttpOnly cookies directly out of headers from Ajax responses.<p>(3) The "best practices" response to XSS isn't just filtering and neutralizing input (by encoding metacharacters to HTML entities); it's also consistently filtering output, so that no matter what garbage ends up in your SQL rows, you still aren't corrupting the DOM with it. Note that filtering (in both directions) is notoriously easy to screw up: for instance, lots of apps catch script tags but miss event attributes.

Too bad it's not reliably implemented cross browser.<p>It's a great idea, though, so we go ahead and throw httponly onto every cookie we care about, even as we implement other measures. We had to hack together something, though, since Python's SimpleCookie class doesn't recognize httponly as a valid cookie attribute.<p>edit: When he says he's not sure if Safari implements it or not, what he means to say is that Safari doesn't implement it. At all.

A much better idea would be to be able to define an html to surround user code (allthough one has to make sure that the usercode will never contain that special tag) and disallow all javascript or other malicious actions in it.

So Internet Explorer is the only browser to attempt to address XSS by properly implementing HttpOnly cookies (by blocking access to the response headers)? Quite disappointing!

You can avoid all of this by using session id cookies and changing the session id for each request.