1) The underlying network library used for Safari - the Qt C++ library - particularly the QNetworkCookie class - has finished adding HttpOnly support! See http://trolltech.com/developer/task-tracker/index_html?id=206125&method=entry for more information on the specific bug. My undercover Safari developer resource tells me that Safari is soon to follow with full HttpOnly support in both the Windows and OSX versions!
2) The latest version of the Servlet 3.0 specification (JSR 315) has added HttpOnly support to both the Cookie and SessionCookieConfig classes. You can download the JavaDoc here. Thank you to Rajiv Mordani @ Sun!
HttpOnly is not a cure-all. It's simply one defense-In-depth measure to assist in preventing XSS session hijacking attacks. HttpOnly can also be circumvented via triggering an AJAX request via the XMLHttpRequest object and reading cookie data out of the headers. Fellow HTTPOnly crusader, Eric Bing from Oracle, is also leading the charge communicating with the w3c regarding future specifications to prevent the XMLHTTPRequest JavaScript object from accessing HttpOnly cookies! Exciting!
In other HttpOnly news:
WebLogic is testing a HttpOnly flag and is currently reviewing the patch "for feasibility".
There is a FireFox bug already addressing the circumvention of HttpOnly via XMLHttpRequest headers as described above. Please consider adding you vote to help encourage the team to lock down this HttpOnly circumvention vector: https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=380418#vote_380418
And the Crusade Continues......
9 comments:
Interestingly the specification for cross domain XMLHttpRequest being proposed requires that cookies cannot be read from the response, so at least on some level the HTML working group recognizes that it is dumb (I am of the opinion that there is very little excuse for the client to be able to read the cookie at all, in any form, but bad web programmers disagree).
On the topic of the cross domain request I still think it is a horrible idea to send cookies in the first place, as neither the end user, nor the 3rd party website have control over the fact that an intermediary website is now able to request priviledged content, other than disallowing off domain requests completely. Fortunately both Microsoft and the Mozilla Foundation seem to agree at the moment, but Opera and various web developers are pushing for it strongly. I hate standards bodies. Democracy sucks when the minority is right and the majority is stupid.
Unrelated, it would be nice if the stupid comments could be edited by the user. if I need to be authenticated to post, allow me to edit google.
I agree with you 100% - I do not understand why any good programmer would need to read cookies on the client in the first place.
I have a problem with JavaScript reading cookies - especially HttpOnly cookies - but transmitting cookies via AJAX requests is another matter, IMO. XMLHttpRequest cross-domain-request standards require server-side policy that disallows cross-domain requests by default (ie: no policy file set in the first place). And disallowing cross-domain requests altogether seems like a reasonable policy in some circumstances. This is one sure-fire was to ensure that a 3rd party site can not access privileged content via a cross-domain request.
It's the social networking community that is driving this specification. But my bank does not need to jump in the game if they do not want to.
I agree, it is absolutely the social networking that wants users to be able to request user specific data from various sources, hence the need to to pass cookies cross domain (in their eyes).
Only sites that specifically want this functionality should implement it (and at least it is disabled by default in the specification), but the problem is that any website that wants to interact with a social networking site would in turn likely allow it to some degree.
Ultimately I don't have issue with content, even user specific content, coming from multiple sources, per se, but I have issue with this method of doing so. This is essentially the client requesting the infromation on a server's behest. Web Application A wants data to be shown from Web Application B so asks the client to grab it, while still ultimately having scrutiny over the data (since it could just send the requested data back to itself via a seperate XML request). In this scenario, Web Application B can authorize the client access to the data, but can't do authorization on Web Application A. To authorize Web Application A you would first need to authenticate it, and from the client any authentication scheme is going to be very weak (any credentials would be in javascript, and it can't reliably authenticate physical properties like IP, host address, etc).
In any scenario like this the developers of Web Application B should want to authorize both the app and the user for the content, as it is the only real protection against malicious use. XMLHttpRequest is not the mechanism to do so at least not in the current form.
A lot of companies are going to get this wrong, and there are going to be a lot of vulnerabilities.
> A lot of companies are going to get this wrong, and there are going to be a lot of vulnerabilities.
You hit the nail on the head. Insightful comments. We can see the clouds, the storm is coming.
All nice and dandy but you can’t steal a session cookie this way.
Why? Simple :
The first request (for the page) will have a Set-Cookie header containing the Session cookie. The subsequent XMLHttpRequest from the page’s javascript code will be issued with that session cookie and the server WILL NOT send again a Set-Cookie for the session cookie.
Therefore session hijacking cannot be done this way as far as I can see.
Correct me if I’m wrong.
Quoting from https://bugzilla.mozilla.org/show_bug.cgi?id=380418
"XMLHttpRequest subverts the idea of HTTPOnly cookies since it allows sending a request and reading out Set-Cookie header of the response - even if it has HTTPOnly flag set. There are quite a few web applications out there that will send out a Set-Cookie header with the session cookie for every request just in case, thus rendering HTTPOnly flag ineffective."
Yes, Manicode, but I consider such a web application (/site/whatever) which sets the session cookie on every request badly designed.
Andrei, I agree with your last comment 100%!!!!
Post a Comment