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

On Fri, 26 Jun 2009, Tyler Close wrote:
> >
> > 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.
> 
> Are you saying the two web-apps should not be allowed to use 
> storage.example.org?

I'm saying that they should use different namespaces for their 
autogenerated file names. For example, the printing app should use 
http://storage.example.com/printing.example.net/spool123 and the photo app 
should use http://storage.example.com/photo.example.com/photo123.

Even better would be for the storage site to use keys in addition to the 
identifiers, so that printer.example.net can give photo.example.com access 
to specific files which photo.example.com can then access, but 
photo.example.com can then do so in a manner that tells the storage site 
that it only wants to be able to access printer.example.net's storage 
area. So then the storage server knows who is accessing the data, which 
decides what the credentials that site needs to present are; it knows the 
file that the site wants to access, and it knows who the file is being 
accessed on behalf of, along with a key to prove that this is being done 
with that site's permission.

But this still doesn't seem to have anything to do with sandboxed iframes.


> > The problem there is simply one of trusting potentially hostile 
> > external input.
> 
> What input validation should photo.example.com have done?

"Is this identifier a file that is definitely owned by 
printing.example.net?"


> > 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.
> 
> There are no sandboxed iframes in this example. It's just a simple web 
> page from a single origin, using CORS for cross-origin resource sharing. 

Oh. Then that isn't what I was talking about. This thread is specifically 
about the use of Origin and Referer and user credentials in the context of 
a sandboxed iframe.


> And it doesn't work. The scenario is not impossible to implement. It is 
> simple using web-keys. It is only impossible to safely implement it 
> using the CORS security model.

That's like saying that it is impossible to secure a beach with a padlock. 
Is anyone saying that CORS is what you would use in this scenario? If so, 
then I agree, they are wrong.

The Origin header just tells the server who sent the request. If you use 
it to let other sites do stuff on your behalf without checking what they 
are doing, then game over. It's not going to protect against that. It 
similarly won't protect against <script src=""> blocks importing scripts 
from untrusted domains.

That doesn't mean Origin doesn't solve some specific problems, such as in 
particular allowing a site to access user-specific information from a 
third-party site (e.g. Google Finance giving the user's financial 
information to a "mashup").

You have to use the right tool for the job.

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

Received on Saturday, 27 June 2009 04:28:48 UTC