Origin header in loading external scripts (ISSUE-63)

Hi all,

Adam Barth said on the IETF HTTPbis list that other specs could define
some additional constraints on when to send the Origin request header
(e.g. CORS and/or HTML5), so I believe this is the right place for
this:

I've a few days ago found a CSRF vulnerability in a product due to
exposing data as JSON and "JSON-P" (JavaScript, where the same JSON
data is passed as an argument to a callback function), where the data
is a "protected resource" (i.e. requires authentication). An attacker
could then load the JSON-P "script" and process the data in its
callback function by sending it back to its own server via
XMLHTTPRequest (or another server via a hidden form); in this case it
could have been for example the list of all the users of the
application, along with their email address.
I suggested them to only allow JSON-P on "public resources", but there
might be legitimate use cases for allowing JSON-P on protected
resources so this is not a real long-term solution (in this particular
case, i.e. for this particular product, there would workarounds, i.e.
some way to "opt in" exposing some data with JSON-P, but not
selectively however, depending on the "origin document").

I therefore suggest that HTML5 *requires* browsers to send the Origin
request header on such GET requests (loading of external scripts),
where the Origin I-D only has a "MAY" for safe methods.
I don't think other kind of requests need to be addressed this way as
this is the only case where an external resource is "imported" within
the pages' "origin" (e.g. images keep their "origin" information that
prevent them from being accessed after they've been painted onto a
<canvas> [1]). Well, there might be CSS stylesheets too, but could
they "leak information"?

[1] http://dev.w3.org/html5/spec/Overview.html#security-with-canvas-elements

-- 
Thomas Broyer

Received on Monday, 26 January 2009 10:29:13 UTC