- From: Jim Manico <jim@manico.net>
- Date: Mon, 16 Jun 2008 08:33:42 -1000
- To: Anne van Kesteren <annevk@opera.com>
- CC: eric bing <eric.bing@oracle.com>, public-webapps@w3.org
- Message-ID: <4856B206.6030306@manico.net>
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