[cap-talk] Fwd: [cors] TAG request concerning CORS &Next Step(s)

[Adam Barth]

On Fri, Jun 26, 2009 at 9:10 AM, Toby Murray<toby.murray at comlab.ox.ac.uk> wrote:
> Hold on a sec. You've already said that Bob's Finance can simply act as
> a browser and visit acme to achieve the same end. Similarly, I can't see
> why Bob's finance can't just send a request to Google with an "Origin:
> finance.acme.com". So with Origin:, Bob can still get and display Google
> finance data on his site.

It's important to distinguish Bob's server-side code from his
client-side code.  The code on the client can't forge the Origin
header.  The server side code doesn't need to forge the Origin header
to access the stock ticker information.

> I didn't realise that the unguessable token alternatives you sought had
> to improve upon the security properties Origin:  but merely show how the
> same end could be achieved, with any extra complexity perhaps paid for
> by better security properties or whatever.

I'm asking how to achieve the same security for the same use case.  If
secret tokens can do even better, that's great, but let's first make
sure we understand how the basic use case works.

>> Here's the CORS approach:
>>
>> When Google Finance receives a request for
>> http://finance.google.com/api/stockticker/MSFT:
>>
>> 1) Let /requesting origin/ be the value of the /Origin/ header.
>> 2) If /requesting origin/ is a member of the /authorized origins/
>> white list, then:
>>   A) Append the Access-Control-Allow-Origin header to the response
>> with the value /requesting origin/
>> 3) Append the header Vary: Origin to the response.  (You can also use
>> Expires or Cache-Control here for a similar effect.)
>
> Indeed, this appears to be subject to the 'attacks' I mentioned above.

Really?  What JavaScript should Bob include on his web site in order
to access the stock ticker information from finance.google.com?

> Can you clarify the goal here -- i.e. what it is we are trying to
> achieve? At the moment, I'm not sure what the criteria are against which
> the unguessable tokens approaches should be compared to the Origin:
> approach.
>
> For instance, is the goal:
>
> 1. to prevent this kind of "authority stealing" (where Bob steals the
> authority of Acme to access Google Finance) or

This is too low-level a goal.

> 2. to allow cross origin XHR whilst not exposing the user unduly to
> CSRF?

No.  We're worried about confidentiality, not integrity.

The problem we're trying to solve is this:

1) Google Finance would like to offer an API to access stock ticker
information that is usable by other web sites.
2) Google Finance would like to restrict which web sites can use the
API (e.g., to charge a fee, enforce a terms of use, etc.).
3) Web sites that access the stock ticker service do not wish to proxy
the API traffic via their servers.

Non-goals:

A) We're not trying to stop Bob's Finance from accessing the stock
ticker information from his server (Bob can always do this by browsing
acme.com).

> The arguments I would make in favour of the unguessable token approach
> are that
>
> a. If the goal is 1. then Origin: may not achieve this purpose any
> better than unguessable tokens.

CORS appears to work well for this use case.  Can you explain why you
think CORS fails to be useful here?

> b. If the goal is 2.

The goal is not 2.

Adam