- From: Tyler Close <tyler.close@gmail.com>
- Date: Fri, 26 Jun 2009 16:10:05 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
Response inline below, so keep scrolling... On Fri, Jun 26, 2009 at 3:41 PM, Ian Hickson<ian@hixie.ch> wrote: > 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. Are you saying the two web-apps should not be allowed to use storage.example.org? > The problem there is > simply one of trusting potentially hostile external input. What input validation should photo.example.com have done? Your above claim basically means a site cannot accept identifiers from potentially hostile sites. That is true when using the ACL model (ie: doing access control based on the origin of a request). I'm suggesting we not use the ACL model, since it is broken in multi-party scenarios like CORS. I leave it as a simple exercise for the reader to redo the above example using web-keys <http://waterken.sf.net/web-key>. The exchanged messages have exactly the same format and there is no additional input validation required. That's because the capability model actually provides access control in multi-party scenarios. >> 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. 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. 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. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Friday, 26 June 2009 23:10:47 UTC