Re: [XMLHttpRequest]HttpOnly cookies visibility in XMLHttpRequest

Anne,

Thanks kindly for all of the information. Hope you do not mind if I 
chime in. Here is a little backstory/status on HttpOnly.

Both the browser and web application security community stand behind 
HttpOnly.

HttpOnly is supported by IE 6/7, FireFox 2/3, Opera 9.5 and Safari is 
currently adding it.

The Web Security community supports HttpOnly strongly, more details 
here: https://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

IE 6/7 and FireFox 2/3 both support HttpOnly in both READING a HttpOnly 
cookie via the JavaScript document.cookie call, as well as writing to 
HttpOnly cookies via JavaScript.

However, there is a workaround in JavaScript that involves making a 
request via XMLHTTPRequest and reading cookies out of the headers. That 
makes the HttpOnly flag almost useless. FireFox has recognized this as a 
bug https://bugzilla.mozilla.org/show_bug.cgi?id=380418 and plans to 
patch. There is also a Opera bug on this topic posted at 
bug-339209@bugs.opera.com. IE recognizes this as a bug, too.

For the sake of security, the browser and web security community would 
be greatful if the text at

http://dev.w3.org/2006/webapi/XMLHttpRequest/#security

Is stronger when talking about HttpOnly protection in JavaScript. We 
need only 3 vectors locked down:

1) Reading of HttpOnly cookies via JavaScript
2) Writing to HttpOnly cookies via JavaScript
3) Reading of HttpOnly cookies from the headers of a XMLHttpRequest via 
JavaScript

If we wait until someone decides to finally define cookies (the current 
standard is the netscape standard from 10 years ago?) then we are 
encouraging the next generation of browsers to expose HttpOnly cookies 
in the XMLHTTPRequest JavaScript object - which is a security flaw.

Thank you or considering,
With respect,
Jim

PS: Might I suggest we change

*Apart from requirements affecting security made throughout this 
specification implementations /may/, at their discretion, not expose 
certain headers, such as headers containing HttpOnly cookies.*

to

*Apart from requirements affecting security made throughout this 
specification implementations /may/, at their discretion, not expose 
certain headers. For security purposes it is recommended that HttpOnly 
cookies should never be exposed via XMLHTTPRequest.*


> Note: due to the wonders of W3C process we now have a new mailing 
> list, public-webapps. I cc'ed it on this e-mail.
>
> On Sat, 07 Jun 2008 00:18:32 +0200, eric bing <eric.bing@oracle.com> 
> wrote:
>> Apologies for the late comments - I belatedly realized the close of
>> comments on this was June 3.
>
> That's ok. Technical comments are _always_ welcome. (Though they may 
> not always impact the transition to CR or some other level, of course.)
>
>
>> I've been discussing some of this internally within Oracle USA and
>> within the OWASP mail lists, and would like to make a suggestion.
>>
>> We're very happy with the mention in the April 15th spec:
>> /Apart from requirements affecting security made throughout this
>> specification implementations /may/, at their discretion, not expose
>> certain headers, such as HttpOnly cookies.//
>> /http://dev.w3.org/2006/webapi/XMLHttpRequest/#security
>>
>> However, we'd like to see even stronger language here.  We think it
>> should be *recommended *or even better yet *required *that
>> XMLHttpRequest not see these headers of HttpOnly cookies.   The fact
>> that XMLHTTPRequest can currently see these cookies greatly undermines
>> the security value of this flag.
>
> I very much agree, but given that nobody has defined cookies yet in 
> sufficient detail making this a hard requirement is not really 
> feasible at the moment. Once someone has defined cookies in sufficient 
> detail we can revisit this.
>
>


-- 
Jim Manico, Senior Application Security Engineer
jim.manico@aspectsecurity.com | jim@manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

Received on Monday, 16 June 2008 20:13:01 UTC