- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 27 Jun 2009 04:28:09 +0000 (UTC)
- To: Tyler Close <tyler.close@gmail.com>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
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