[cap-talk] XHR and sandboxed iframes (was: Re: XHR without user credentials)

David Wagner daw at cs.berkeley.edu
Mon Jun 22 22:27:28 EDT 2009


Ka-Ping Yee  wrote:
>   - The Origin header is intentionally coarse-grained (to the entire
>     site) and the origin site doesn't get to choose when this header
>     (i.e. this bit of ambient authority) is sent -- it's always sent for any
>     page on their site.  Does this mean that instead of having to carefully
>     security-audit just the pages that exercise the remote site's authority,
>     the origin site is now obligated to scrub every page on the entire site
>     for possible maliciously-submitted links and <img> tags?
>
>       - What about sites like Gmail where user-generated links and
>         <img> tags show up all the time?  Would the Origin header be useless
>         for such sites then?

I think the Origin: proposal requires, as a precondition, that GET
requests never have any security relevant side effects: i.e., it assumes
that the web server is designed so that state-modifying requests can
only be done via POST, not GET.  This has long been a rule that web
servers are "supposed" to follow (for instance, it is in HTTP RFC),
though not all of them follow it.

If there is any GET request you can send to the web server that will
cause it to mutate the server-side state, then the Origin: proposal will
not protect against CSRF attacks on that GET request.  To put it another
way, the Origin: header only makes sense for web sites that are careful
to ensure that GET requests cannot mutate server state.

The next thing to understand is that, under the Origin: proposal,
the Origin: header would only be sent for POST requests, not for GET
requests.

So, if Gmail is careful to avoid state-mutating GETs, then Gmail
does not need to scrub all maliciously-submitted links and <img> tags.
That's because those links and <img> tags will trigger GET requests,
which are harmless and cannot be used for CSRF, and the browser does
not attach a Origin: header to those requests anyway.

Of course, if Gmail allowed user-generated links in a form with a
POST action, then yes, Gmail would have to carefully scrub those links
carefully.  But that's probably a rarity.

So unless I missed something, I don't think this is a serious flaw.
Perhaps it should be documented carefully in the Internet-Draft [1],
as I don't see it described either there or in the research paper [2],
but it doesn't seem like a devastating showstopper.  What do you
think?  Do you disagree?

[1] http://tools.ietf.org/html/draft-abarth-origin-00
[2] http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf 


More information about the cap-talk mailing list