Manicode

Some of the most recent iterations of the XHR specification at w3c (edited by Anne van Kesteren) includes excellent security choices which will lock down the JavaScript HTTPOnly edge-case exposure vectors.

The latest editorial draft of the XHR w3c spec http://dev.w3.org/2006/webapi/XMLHttpRequest/

• prevents creating set-cookie/2 headers via setRequestHeader() in a case insensitive way. (but XHR is free to send Cookie/2 headers for any existing cookie (HTTPOnly or otherwise).
• prevents reading set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way.

Excerpts from the spec:

getAllResponseHeaders(), method….
Return all the HTTP headers, excluding headers that case-insensitively match Set-Cookie or Set-Cookie2, as a single string, with each header line separated by a U+000D CR U+000A LF pair excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

setRequestHeader(header, value), method
For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers:
• Accept-Charset
• Accept-Encoding
• Authorization
• Connection
• Content-Length
• Cookie
• Cookie2
• Content-Transfer-Encoding
• Date
• Expect
• Host
• Keep-Alive
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via

I’m excited to see this key specification move in such a secure direction!