Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)

On Fri, 26 Jun 2009, Tyler Close wrote:
> 
> Consider two web-applications: photo.example.com, a photo manager; and 
> printer.example.net, a photo printer. Both of these web-apps use storage 
> provided by storage.example.org. We're going to print a photo stored at: 
> <https://storage.example.org/photo123>
> 
> 1. A page from photo.example.com makes request:
> 
>     POST /newprintjob HTTP/1.0
>     Host: printer.example.net
>     Origin: photo.example.com
> 
>     HTTP/1.0 201 Created
>     Content-Type: application/json
> 
>     { "@" : "https://storage.example.org/job123" }
> 
> 2. To respond to the above request, the server side code at
> printer.example.net set up a new printer spool file at
> storage.example.org and gave photo.example.com write access to the
> file.
> 
> 3. The same page from photo.example.com then makes request:
> 
>     POST /copydocument HTTP/1.0
>     Host: storage.example.org
>     Origin: photo.example.com
>     Content-Type: application/json
> 
>     {
>         "from" : { "@" : "https://storage.example.org/photo123" },
>         "to": { "@" : "https://storage.example.org/job123" }
>     }
> 
>     HTTP/1.0 204 Ok
> 
> That's the expected scenario. Now, what happens if in step 1,
> printer.example.net responds with URL
> <https://storage.example.org/photo456>, another photo belonging to
> photo.example.com. The POST in step 3 now looks like:
> 
>     POST /copydocument HTTP/1.0
>     Host: storage.example.org
>     Origin: photo.example.com
>     Content-Type: application/json
> 
>     {
>         "from" : { "@" : "https://storage.example.org/photo123" },
>         "to": { "@" : "https://storage.example.org/photo456" }
>     }
> 
>     HTTP/1.0 204 Ok
> 
> Consequently, one of the user's existing photos is overwritten with a
> different photo.
> 
> The general point exemplified by the above scenario is that a site 
> cannot safely make a request that includes an identifier received from a 
> third-party, when access-control is based on the origin of a request.

I don't understand why photo.example.com would trust the identifier from 
printer.example.net if the latter could be in the same namespace as the 
namespace photo.example.com uses for its own data. The problem there is 
simply one of trusting potentially hostile external input.


> The point of CORS is to enable sites to exchange messages. These 
> messages will include identifiers. When an identifier is taken from a 
> response and put into a request, a Confused Deputy vulnerability is 
> created by CORS. The redirect example is just an automated way of doing 
> this transfer of an identifier from a response to a request. CORS could 
> prevent such vulnerabilities by not identifying the origin of requests.

I don't understand why this is any different in sandboxed iframes than 
anywhere else. I don't disagree that redirects complicate matters mildly, 
but that is the case regardless of whether there is a sandboxed iframe or 
not as far as I can tell. My point was that without the user credentials 
in the sandboxed origin, it would be impossible for the page to even get 
to the original photo data, let alone contact the printing site or the 
storage site and get them to print a photo.

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

Received on Friday, 26 June 2009 22:42:40 UTC