Security-sensitive headers

Here is a suggestion to future-proof the XMLHttpRequest Level 2
handling of security-sensitive headers.

Currently Section 3.4 contains a list of 17 blacklisted headers
(Accept-Charset, Accept-Encoding, etc.), and one blacklisted header
prefix (Proxy-). There is no mechanism for the creation of new
security-sensitive headers, except those with the "Proxy-" prefix. If
a user agent comes up with a new header to be used for security
purposes, it is difficult for web sites that receive this header to
know whether the header was set by unprivileged JavaScript or by the
user agent. It is particularly hard for web servers because the
User-Agent header is not security-sensitive, and thus cannot be used
reliably to distinguish new browsers from old ones. The user agent
could disambiguate these cases for the web server by prefixing the
header with "Proxy-" but this prefix may not be suggestive of the true
purpose of the header.

Here are some approaches that could address this issue:

Approach 1: Create a prefix denoting headers that are determined by
the user agent and cannot be overwritten by unprivileged JavaScript.
For example, "UA-" or "Sec-". This is the approach we prefer.

Approach 2: Adopt a whitelist approach instead of a blacklist
approach. The spec could provide a list of unprefixed headers that can
be overwritten (If-Modified-Since, User-Agent, etc.) as well as a
whitelisted header prefix (X-). Unfortunately, this approach would put
limits on standardization of new HTTP headers, because older
implementations of XMLHttpRequest would be unable to set them.

Approach 3: Add a security-sensitive header that specifies which
headers have been overwritten by unprivileged JavaScript. This
approach puts the burden on checking for header spoofing on proxies
and servers, rather than the browsers.

The specific use case that Adam Barth and I are working on is defining
a new HTTP header that indicates cookie integrity. The Set-Cookie
header provides confidentiality using the Secure flag, but the Cookie
header provides no corresponding mechanism for indicating integrity;
thus the server cannot distinguish cookies that were set over HTTP
from those that were set over HTTPS. It would be nice not to have to
worry about XMLHttpRequest setting this header, but under the current
specification we'd have to chose a header name that starts with
"Proxy-". There have been many other proposals for new
security-related HTTP headers (e.g. content restrictions) so it would
be nice to solve this issue in general.

Another related issue that would be good to standardize is the
handling of the Cookie header. Internet Explorer 6 and 7 doesn't
appear to allow Cookies to be set using XMLHttpRequest at all. Firefox
2 allows pages to use XMLHttpRequest to set a Cookie header, but
merges the user-set header with the user agent header:

Cookie: [actual cookies values]; [user-set Cookie header value]

I've heard some arguments for removing Cookies from cross-site
XMLHttpRequests, which indicates to me that the Cookie header might be
a good candidate for adding to the security-sensitive list.

-- Collin Jackson

Received on Wednesday, 20 February 2008 16:44:23 UTC