Re: [cors] unaddressed security concerns

Hi Maciej,

Responses inline below...

On Wed, Nov 4, 2009 at 9:36 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Nov 3, 2009, at 5:33 PM, Tyler Close wrote:
>> 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.
>
> What's the attack here? Is it information disclosure or vandalism?

The problem is information disclosure. My understanding of your
proposed design was that photo.example.com would grant read access
over a file to printer.example.net and send the file's URL to
printer.example.net. The printer.example.net would then use its own
credentials to read the file content, print it out and mail it to the
recipient. In the legitimate case, photo.example.com grants read
access to a photo file that it owns. In the attack case,
photo.example.com sends a URL for the printer.example.net client list.
The printer.example.net site already has permission to read its own
file, so it prints it out and mails it to the attacker.

Perhaps this design is not what you originally intended, but it was my
understanding from the original email:

http://www.w3.org/mid/5D7511B2-DA9D-40AF-A536-D799FB6EEFD8@apple.com
"""
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. 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.
"""

Either way, this was an older email and I am happy to move on to
discuss your most current thinking on this topic.

> That being said, my understanding of this threat was greatly improved by the
> discussion at TPAC. I now think the best way to address multi-site
> collaboration is by applying the DBAD discipline. Here's how I would do it
> in this case:
>
> The storage service is designed to allow collaborative access by multiple
> sites, therefore it needs to let them distinguish their own requests from
> third-party requests. One way to do so is to partition resources such that
> each is owned by exactly one storage domain. The only way to share
> information cross-domain is to copy. Resource names include the domain that
> owns them. Then it offers the following command set (angle brackets are used
> to delimit metasyntactic variables):
>
> (This may be more complicated than needed, for the sake of clarity):
>
> Read <from>
>   If the <from> resource is owned by the domain specified by Origin, return
> the data.
>
> Write <to>\n
> <filedata>
>   If the <from> resource is owned by the domain specified by Origin, store
> <filedata> at the resource.
>
> SameDomainCopy <from> <to>
>   <from> and <to> must be in the same domain and must match Origin.
>
> GetReadToken <resource>
>   If the Origin header matches <resource>, return a one-time read token
> which can be used to copy a resource cross-domain
>
> GetWriteToken <resource>
>   If the Origin header matches <resource>, return a one-time read token
> which can be used to copy a resource cross-domain
>
> CrossDomainCopy <from-domain> <from-resource> <read-token> <to-domain>
> <to-resource> <write-token>
>    <read-token> must be a valid read token for <from-resource>, and
> <from-resource> must be owned by <from-domain>. <write-token> must be a
> valid write token for <to-resource>, and <to-resource> must be owned by
> <to-domain>. Origin must match at least one of <from-domain> or <to-domain>.
>
> This allows two sites to agree to copy a resource from one to the other on
> storage.exmple.org without introducing a confused deputy hazard.
>
> In the original scenario, photo.example.com would get a resource name and a
> write token from printer.example.net, would obtain its own read token for
> the resource to copy using GetReadToken, and then issue a copy request with
> both domains and both tokens using CrossDomainCopy. It's impossible for
> printer.example,net to make photo.example.com accidentally overwrite its own
> resources in this case, because the request on behalf of a third party is
> distinct from any request it would make on its own behalf. You could argue
> that neither Origin nor Cookie in the cross-domain network resources are
> necessary to make this work,

Indeed. By adopting the explicit permission passing style that I
advocate for, you have avoided the CSRF-like attacks that are a danger
when relying on Origin and Cookie. *It seems we both recognize that
relying on Origin and Cookie is dangerous.*

The Read, Write and SameDomainCopy methods still rely on Origin and
Cookie, so the code will have to be very careful not to use these
operations with a URL received from another site. For example, if
Origin A sends a URL to Origin B, then Origin B's code must be careful
to never use that URL in a Read, Write or SameDomainCopy operation, or
a CSRF-like attack would occur. This danger could be eliminated by
using explicit permission passing for these operations as well.

> but I think in this case they can make the system easier to build and more robust.

That part is unclear to me. I can clearly see some costs that have
been created: additional unnecessary parameters; hard restrictions on
the structure of the URL namespace; and a loss of flexibility in the
API. For example, it's not possible to just give another service an
output file that it can simply write to. It must write its output to
its own file and then copy the data to the output file. The
cross-domain part of the API seems determined to make some use of
Origin, but to what advantage is unclear.

>> 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.
>
> I don't really agree that composing a request from data received from 2 or
> more sites is likely to be common. Sites are doing cross-domain
> collaboration now, using techniques like OAuth, JSONP, or asking the user
> for their password for another site.

You say you don't agree, but your examples are of requests composed of
data from 2 or more sites.

> To my knowledge, the sites doing this
> are general having a pure bilateral interaction that is well modeled by the
> example in my CORS background slide.

I don't understand this last sentence.

Closing remark:

In another thread, you've written "I do think that a way to do an
anonymous XHR is justified", so I don't know how much sense it makes
to continue this thread. You put so much effort into this email that I
felt I owed you a response.

Cheers,
--Tyler

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

Received on Friday, 6 November 2009 01:48:52 UTC