W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [cors] unaddressed security concerns

From: Tyler Close <tyler.close@gmail.com>
Date: Tue, 3 Nov 2009 17:33:48 -0800
Message-ID: <5691356f0911031733s5b368764re54fe926d4d1ad32@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
I was just catching up on email and thought it might be useful to
respond to this one even though it's a couple weeks old now, since in
general the group seems to want more examples.

On Mon, Oct 12, 2009 at 7:19 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> As a side note, I should add that Tyler's scenario would be much simpler
> overall if printer.example.net used a grant of read access to the photo it
> wants to print on storage.example.org, instead of granting write access to a
> new location.

In this scenario, photo.example.com has the opportunity to take the
role of attacker in a CSRF-like attack. In the legitimate case,
photo.example.com is expected to send a URL to printer.example.net
which identifies the photo to be printed, such as
<http://storage.example.org/photo123>. In the attack case,
photo.example.com could send the URL that identifies the
printer.example.net client list, such as
<http://storage.example.org/clients123>. Consequently,
photo.example.com receives a print out of the printer.example.net
client list, instead of a photo printout.

> Or it can just ask photo.example.com to read the photo from
> storage.example.org and send the actual data. Either of these much less
> abusable than writing, and would be a safer approach, whether or not the
> overall design depends on secret tokens. The grant of read access can be
> one-time or time-limited if necessary. Thus, I think the scenario is
> somewhat contrived. Likely cross-site interactions would not involve such a
> complex process to transfer data. The root of the vulnerability in Tyler's
> scenario is writing in a shared namespace to transfer data, instead of
> simply granting read access to the existing copy, or transferring the actual
> data bits.

The semantics of the request, read versus write, are not relevant to
the attack. As Maciej explained in the TPAC meeting today, the actual
problem occurs when a request is composed using data received from 2
or more sites. As an historical note, it's interesting to observe the
initial misstep here and so conjecture that web developers may also
misunderstand the dangers and so use CORS-with-Origin in an insecure

A request composed from data received from 2 or more sites should be a
common pattern in any *cross-origin* application. It's the nature of
the problem space. There's no need for examples to be complicated to
demonstrate the problem. If people find Maciej's example simpler, it
demonstrates the vulnerability just as well.


"Waterken News: Capability security on the Web"
Received on Wednesday, 4 November 2009 01:34:21 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC