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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)
Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com
