Sunday, June 15, 2008

Opera 9.5 HttpOnly Read Prevention

Opera 9.50 is now available for download at

Although the official release documentation did not mention it, Opera 9.50 does indeed include the most basic form of HttpOnly support - HttpOnly cookie read prevention. The following results are from Opera 9.50 on Vista Ultimate. I tested using the WebGoat v5.1 HttpOnly test page at /WebGoat/attack?Screen=176&menu=51.

And here are the official results:

* SUCCESS: Your browser enforced the HTTPOnly flag properly for the 'unique2u' cookie by preventing direct client side read access to this cookie.
* FAILURE: Your browser did not enforce the write protection property of the HTTPOnly flag for the 'unique2u' cookie.
* The unique2u cookie was successfully modified to se/M3Lw5Ia4cMyKIUAJrbz23Ibo= on the client side.
* FAILURE: Your browser does not prevent an XMLHTTPRequest read for the 'unique2u' cookie.

This is obviously not perfect support; we should at least see HttpOnly write prevention. Current versions of IE 6/7 and FireFox 2/3 all include both HttpOnly cookie read and write prevention per OWASP's HttpOnly browser support section.

However, this is still another victory for HttpOnly crusaders and Web Application Security. I'll be sure to post a bug on Opera's support site requesting complete support.

And don't forget to vote for the Firefox "XMLHttpRequest allows reading HTTPOnly cookies" bug at so we can have at least one browser with complete HttpOnly support!


Jim Manico said...

Opera bug posted requesting complete HttpOnly support -

Jim Manico said...

Opera HttpOnly support has been around since Opera 9.5 Beta 1

kuza55 said...

You seriously need to find a more relevant crusade; httpOnly is completely useless in 99% of cases.

In any case, none of the browsers prevent cookies with the same name, but a different path or domain being written, and so it is almost always possible to over-write the cookie when necessary (just by flooding the browser with a bunch of cookies with all the folders and files in the root directory, you can't change the cookie for the absolute root; but that's pretty irrelevant)

Jim Manico said...


Jim Manico said...

I am not certain I follow your comment. A cookie is only set server-side; a programmer, via server code, cannot create or modify a cookie in a response for a different domain.

So I'm not sure what you mean by "prevent cookies with the same name, but a different path or domain being written" - I would love to hear more about this attack.

HttpOnly is just one small crusade to help enhance the security of today's web technologies. Sure it can be circumvented in a variety of ways - but it still lowers the risk against session-stealing XSS attacks.

kuza55 said...

Cookies can be set with javascript, just do document.cookie='name=value';

And cookies can be set for other domains, namely any domain above the current domain in the domain tree (i.e. can set a cookie for, but the more important issue is that by setting a different path you can effectively over-ride the httpOnly cookie, visit this link: then refresh it once it's finished loading (I'm too lazy to split it up into two pages) and you'll see that the httpOnly cookie is effectively over-written for the server (the $_COOKIE variable is dumped to the page), even though the original httpOnly cookie also exists, server-side code only sees the most specific cookie for a given cookie name.

Jim Manico said...

Cookie overriding like you are describing can only occur within one domain hierarchy. Domain cannot depoy code to override's cookies.

kuza55 said...

Yes, I realise; the comment was simply there for completeness, note that the attack I describe relies on the path attribute, and since we're talking about HttpOnly cookies here, we've already assumed that the attacker has xssed the site.

Jim Manico said...

Surely. And once the site can be XSS'ed, it's game over with all current browsers. That's why I'm trying to encourage different platforms (browsers, namely) to support *complete* HttpOnly protection - which includes read, write and XMLHTTPRequests prevention/protection.

And frankly, encoded data in way that completely protects your site from XSS is not that difficult, see:

Anonymous said...

Hello. And Bye.