Re: Security-sensitive headers

On Feb 19, 2008 1:10 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 19 Feb 2008 02:21:31 +0100, Collin Jackson
> <collinj@cs.stanford.edu> wrote:
> > 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.
>
> Given that older clients and malicious clients will be vulnarable why is
> that not a problem going forward? I'm fine with doing this though.

The goal of security restrictions on headers is to protect a
non-malicious user agent's resources (IP address, cookies, etc.) from
being misused by mobile code that has been loaded by user agent. If
the user agent itself is malicious, there's nothing for the attacker
to steal that the attacker doesn't already control.

Correctly handling older user agents is certainly an important issue.
Older user agents will not be able to easily send cross-site
XMLHttpRequests, limiting the attacker's options. It is still be
possible to send cross-site XMLHttpRequests in older user agents using
DNS rebinding, but Host header checking can mitigate this issue. Users
can also upgrade their user agent to benefit from increased security.

> > 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.
>
> What are those arguments?

The main issue with the Cookie header in cross-site XMLHttpRequests is
these cookies are considered third-party cookies because they can be
used by ad networks to track users across domains. Firefox 3 blocks
third-party cookies by default:
<http://kb.mozillazine.org/Network.cookie.cookieBehavior>

In addition to privacy concerns, there are some security concerns. GET
requests aren't supposed to have side effects. However, sometimes they
do so unintentionally (the server doesn't bother checking the
request's method) and sometimes they do so intentionally (e.g. adding
searches that you've made to your Google search history). Thus, a
cross-site GET request may be dangerous, even if the attacker can't
read back the response.

One technique to prevent cross-site request forgery is to use HTTP
headers. The Referer header isn't reliably present, and the
Referer-Root header isn't deployed yet, so instead you just define
your own header instead and make all requests using XMLHttpRequest.
The idea is that XMLHttpRequest can't be used to set headers across
origins, and a cross-domain form can't be used to set headers at all,
so if the request includes a custom header (e.g. X-CSRF-Defense) then
you know the request is legitimate. However, XMLHttpRequest Level 2
would allow an attacker to make a GET request with the user's cookies
that also includes the X-CSRF-Defense header. The attacker wouldn't be
able to read back the response (since the Access-Control information
is missing) but reading back the response is not necessary for a CSRF
attack. It may be safer not to send the user agent's cookies in a
cross-site request in this scenario.

Another technique to prevent cross-site request request forgery is to
store a session ID in a cookie and embed that session ID as a hidden
input field in every form. When the server receives a request, it
compares the cookie with the hidden input field and accepts the
request only if they are non-empty and equal. However, if the Cookie
header is not considered security-sensitive, XMLHttpRequest Level 2
would allow an attacker to make a GET request that includes a session
ID in both the a query parameter and the Cookie header. Since the
fields match, the server might be confused into accepting the request.
In this scenario, it may be safer not to allow the attacker to set a
Cookie header on the cross-site XMLHttpRequest.

These examples are not exhaustive, and I have no idea how many web
applications might be affected, but they do illustrate that the Cookie
header should be handled with care.

-- Collin Jackson

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