Opera 9.50 is now available for download at http://www.opera.com.
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:
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 https://bugzilla.mozilla.org/show_bug.cgi?id=380418 so we can have at least one browser with complete HttpOnly support!
Subscribe to:
Post Comments (Atom)
10 comments:
Opera bug posted requesting complete HttpOnly support - bug-339209@bugs.opera.com
Opera HttpOnly support has been around since Opera 9.5 Beta 1 http://www.opera.com/docs/changelogs/windows/950b1/index.dml
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)
Heretic!
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.
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. www.google.com can set a cookie for google.com), but the more important issue is that by setting a different path you can effectively over-ride the httpOnly cookie, visit this link: http://kuza55.awardspace.com/httponly.php 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.
Cookie overriding like you are describing can only occur within one domain hierarchy. Domain www.evil.com cannot depoy code to override www.mysecuresite.com's cookies.
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.
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 - http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly 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: http://manicode.blogspot.com/2008/08/input-validation-not-that-important.html
Hello. And Bye.
Post a Comment