Re: Origin header in loading external scripts (ISSUE-63)

On Mon, 26 Jan 2009, Thomas Broyer wrote:
> 
> 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"?

I dicussed this with Adam and we concluded that the problems involved in 
sending the Origin header for GET (namely, leaking intranet host names to 
the Internet) are a blocker.

However, I agree that we need to resolve the above problem also. In 
practice I believe that this is actually the same problem as we 
have with <video>, namely that there needs to be a way to do the opposite 
of what CORS does -- take a resource that would normally be visible to 
anyone, and make it only visible same-origin.

Thus I believe this is an issue for CORS v2, which I expect will be 
addressed in the same timeframe as <video> v3.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 2 June 2009 20:58:55 UTC