W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Tyler Close <tyler.close@gmail.com>
Date: Fri, 26 Jun 2009 15:02:51 -0700
Message-ID: <5691356f0906261502t562b74dakc4c23e4b47984a89@mail.gmail.com>
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>
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

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.


"Waterken News: Capability security on the Web"
Received on Friday, 26 June 2009 22:14:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC