W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [XMLHttpRequest]HttpOnly cookies visibility in XMLHttpRequest

From: eric bing <eric.bing@oracle.com>
Date: Mon, 07 Jul 2008 14:24:03 -0700
Message-ID: <48728973.30805@oracle.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: public-webapps@w3.org, Jim Manico <jim@manico.net>

Thanks Bjoern for laying out the reasoning here.  I'm going to make one 
more tilt at the windmill...

What I'm hearing from you and Anne is that you don't disagree with the 
basic principle that XHR should not be able to be able to access 
HttpOnly cookies.  But rather that this spec is not the correct place to 
address this issue - because (I hope I'm restating these correctly)
1) It belongs in the (sadly non-existent) spec of cookies
2) It should be obvious to implementers
3) We can't list out all security implications - for various reasons 
we'll miss some and weaken all security

I have to respectfully disagree with 2 - this was fixed for plain 
javascript access to cookies, but the XHR portions were left out in in 
IE6 and Firefox 2.  For background on the Firefox fix - check out

Please note particularly in this bug that the Firefox developers were 
nervous about implementing this without it being explicit in this spec, 
so they at least were looking to this spec for guidance on this point:

Daniel Veditz <mailto:dveditz@cruzio.com>  2007-07-10 05:01:21 PDT

I'd feel better if we got some buy-in from other browser vendors/web app
developers on the webapi mailing list and got some consistent restrictions
embedded in the spec (http://www.w3.org/TR/XMLHttpRequest/)

As for points 1 and 3, I do agree with them in the abstract.  But the 
fact is that this spec is the only game in town, and this an issue that 
has been missed by implementers.  There are real consequences to not 
acting now (web sites will be more vulnerable) and mentioning this as a 
recommended requirement seems like a small price to pay to make 
javascript safer.

By the way, for anyone who isn't actually familiar with the issue in 
question, the above bug also has a good example of the vulnerability. 

To test you can go to http://www.yabbforum.com/community/ and use this 
javascript:var req = new XMLHttpRequest();req.open("GET", "/community/", 

Thanks again for your time!
-Eric Bing

Bjoern Hoehrmann wrote:
> * eric bing wrote:
>> I understand the issues around the lack of a cookie definition, and we 
>> suspected that this was the reason this hadn't been addressed more 
>> forcefully.
> I was the one who proposed the addition of the section along with the
> note about HttpOnly, and my proposal did not address this more force-
> fully for two reasons. The less important reason is that the interface
> is used in enviroments where considerations for web browsers do not
> apply (for example, in server-side applications and shell-scripts).
> More importantly, it would seem to me that HttpOnly cookies would be
> defined along the lines of saying that scripts running in web browsers
> should not be given access to them. Therefore a requirement to the same
> effect in the XHR specification would not only be redundant and mis-
> placed, it would also suggest implementing HttpOnly cookies but making
> the cookies available to scripts running in web browsers would somehow
> be valid.
>> In my mind, you've already started down the slippery slope by mentioning 
>> HTTPOnly cookies at all (not that I think that's a bad thing).  If we 
>> use the language that Jim mentions below (/recommend/) we can avoid 
>> making this a hard requirement but give real guidance to folks 
>> implementing the spec.
> Someone struggeling with the question whether HttpOnly cookies should
> be made available to script code that doesn't have access to the cookie
> property of the document object should not be allowed anywhere near web
> browser code. The draft mentions HttpOnly cookies because an informed
> reader of the specification would realize upon mentioning them that im-
> plementers not only may, but have to make security decisions beyond the
> ones detailed in the specification. Without an example like it readers
> might dismiss the note as boilerplate prose.
> The specification obviously cannot detail all the security decsions an
> implementer has to make, consider for example how it would look like if
> HttpOnly cookies had been introduced prior to the XMLHttpRequest object,
> along with how well most specifications are maintained and updated. All
> in all, I am afraid following your suggestion might make matters worse
> security-wise.
Received on Monday, 7 July 2008 21:26:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC