W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] CSRFs and Origin header and <form>s

From: Adam Barth <whatwg@adambarth.com>
Date: Sat, 29 Nov 2008 23:42:29 -0800
Message-ID: <7789133a0811292342x668ed89dx6471229526b8e502@mail.gmail.com>
On Sat, Nov 29, 2008 at 11:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> Regarding which spec to put things in -- what are the cases you want this
> header to be included for? Just form submission? All navigation? All
> network traffic including, e.g., <script src="">, <img src="">, <link rel=
> stylesheet href="">? Just POSTs? All methods?

Different people I've talked to have had different opinions about
whether the header should be sent for all requests or just for
non-GET, non-HEAD requests.  I think it makes the most sense to send
the header for non-GET, non-HEAD requests for a couple of reasons:

1) It side-steps some of the issues with redirects because the most
common redirects generate GET requests.

2) It helps sites not get confused if they contain user-supplied
content like hyperlinks or image tags that can generate "same-origin"
GET requests.  (It's very uncommon to let users supply content that
can generate POST requests.)

3) It has better privacy properties because it doesn't leak
information when an intranet site has a hyperlink to an Internet
(e.g., a competitor's) site.  (It's much less common for an intranet
site to POST a request to an untrusted Internet site.)

4) It avoids some murky issues about what the Origin should be for
some kinds of requests, like dependent loads from style sheets (e.g.,
should the Origin be based on the document URL or the style sheet
URL?).

The disadvantage of not including the Origin header for GET requests
is that sites have to work harder to adopt the Origin header as a CSRF
mitigation.  Specifically, they must make sure they don't modify state
on GET requests.  This might be hard to retrofit onto existing sites,
but the retrofit can still be done at the web application firewall
level, which is still a big win over secret-token based CSRF defenses
which have to modify the application's code.

In practice, this design means we'd want the header to be sent for
<form> POSTs and for XMLHttpRequest.  XMLHttpRequest already sends the
Origin header for cross-site requests, but this would add the header
for same-site XMLHttpRequests that use methods other than GET or HEAD.

The WebKit nightlies have an experimental implementation if you want
to see how this would work.  The WebKit implementation hasn't been
updated with the redirect behavior yet because that is still under
discussion.

Adam
Received on Saturday, 29 November 2008 23:42:29 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC