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

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