Re: Security-sensitive headers

I just realized that I missed that the header security restrictions on
same-origin requests are different from the restrictions on cross-site
requests. Only the "Accept" and "Accept-Language" headers can be set
for cross-site requests.

This policy is much more restrictive -- perhaps overly so, since
authors are encouraged to use setRequestHeader to set the (prohibited)
Content-Type header in Section 3.5.3.

These parts of my previous email are true regardless of the header
policy for cross-site requests:

On Feb 19, 2008 1:07 PM, Collin Jackson <collinj@cs.stanford.edu> wrote:
> 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.
> ...
> 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>

These portions of my previous email relied on attackers being able to
set headers in cross-site requests other than "Accept" and
"Accept-Language".

On Feb 19, 2008 1:07 PM, Collin Jackson <collinj@cs.stanford.edu> wrote:
> 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.
> ...
> 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.

Received on Wednesday, 20 February 2008 16:42:30 UTC