- From: Collin Jackson <collinj@cs.stanford.edu>
- Date: Tue, 19 Feb 2008 17:51:34 -0800
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: public-webapi@w3.org, "Adam Barth" <abarth@cs.stanford.edu>
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