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

On Thu, Jun 18, 2009 at 12:32 AM, Ian Hickson<ian@hixie.ch> wrote:
> On Wed, 17 Jun 2009, Mark S. Miller wrote:
>> >
>> > I don't really understand what we're trying to prevent here.
>>
>> Confused deputies such as XSRF problems. Original paper is at <
>> http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html>. It's well worth
>> rereading. Much deeper than it at first appears.
>
> Could you describe a concrete attack that you are concerned about? I don't
> really see how the article you cite applies here.
>
>
>> Perhaps my own <srl.cs.jhu.edu/pubs/SRL2003-02.pdf> may help.
>>
>> The threads and links already cited should make the connection with
>> browser security clear.
>
> Maybe I'm just too stupid for this job, but I don't understand the
> connection at a concrete level. I mean, I think understand the kind of
> threats we're talking about, but as far as I can tell, CORS takes care of
> them all.

The problem with redirects that is still outstanding against CORS is a
concrete example of the general Confused Deputy issues with CORS. A
redirect is just one way for a site to pass an identifier to code from
another site. Confused Deputy vulnerabilities will occur in CORS
whenever an identifier (such as a URI) is passed from one site to
another. For example...

>> I'm not really sure what more to explain. Perhaps you could ask a more
>> specific question?
>
> Could you show some sample code maybe that shows the specific threat you
> are concerned about?

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. 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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Friday, 26 June 2009 22:14:51 UTC