Re: Re: [XHR] anonymous flag

>>> Does anyone have real, non-contrived use cases for the anonymous flag?

>> The basic idea was preventing confused deputy attacks by not exposing
>> any information that could be used as such. So no credentials and no
>> data about where the request originated from, forcing the architecture

>> to be token-based effectively.

> I think the strongest use-case that I've been able to think of is to
> enable a website to take a URL from an untrusted source and then
> interact with that URL over HTTP.

I can see this as a conceptual or theoretical use case, but I'm not sure I can come up with a real-life scenario where one might want to do this. I can see some non-XHR use cases for expecting users to supply an un-trusted URL ("Over there is the custom style sheet or background image I want on my blog"), but I can't see any realistic XHR-based use case.

Say, for example, OpenID is a setup where the user might provide an "untrusted" URL to a third-party web site ("Here's the service that can authenticate me"), and XHR might be involved - but the Open ID *provider* would of course want to know what site it is interacting with, to present some information about what authenticating means to the user..
> By removing both user credentials and website credentials the website
> doesn't have to worry about confused-deputy problems. I.e. if website
> A gets a URL from untrusted source B, A can then interact with that
> URL without having to worry about that the server that it's
> interacting with will think "oh, this request is coming from A, it's
> fine to trust it then". I.e. it doesn't have to worry about B tricking

> it into taking actions which A has access to, but that B doesn't.

Let's call the third party site C, to go with the alphabet. C serves resources with Access-Control-Allow-Origin: A.

B wants to either carry out an action or get content which B is not authenticated to do, but C might be set up to allow for requests originating from A. A already knows that B's cookies/HTTP auth/SSL credentials won't be sent by default with the XHR request to the foreign URL. However, we expect A to figure out and implement that it should also add an anonymous flag to its XHR requests, to preemptively avoid attacks against C. How do you even start explaining to authors when to use anonymous mode? Why doesn't the attacker B simply type or paste a bookmarklet that triggers a non-anonymous XHR (or trick the authenticated user of A into pasting one and sending the results)? Why doesn't B just write a PHP script that fakes the Referer and Origin headers in a request to C without involving A at all?

> This doesn't need to be obviously harmful "permanently delete files"
> types of actions. For those A would likely need to include some form
> of credentials anyway since any server-to-server communication can
> claim to be from A using origin/referer headers.


> It can also be simpler things like throttling bandwidth if it's

> getting too many requests from a particular source.

AFAIK here your assumption is that 
- C is getting too many requests from B, starts blocking/throttling
- C still accepts requests from A (but not anonymous requests)
- A lets some user input a URL that it will *hammer* with XHR requests
- The developer working on A realises there is an exploit potential and preemptively adds an anonymous flag
 - C no longer accepts the requests B makes A make

Yay, all problems are resolved!? Hm.. My assumptions: 

- Quite likely some or all of the resources A want to fetch are now unable to detect that requests come from A, and hence stop serving them (or don't know what value to put in the Allow-Origin header, amounting to the same thing), 
- A's service becomes crippled.
 - A developer gets support requests, regrets, and removes the anonymous flag

If C accepts anonymous requests in the first place, B can do anonymous requests from its own site when C starts throttling based on origin. Or indeed do backend requests with fake headers.

As far as I can tell, the problem we're trying to solve with the anonymous flag is for all practical scenarios already solved by withCredentials. Any service that's only "protected" by checking Referer and/or Origin header is already really flawed and vulnerable to server-to-server attacks. These are much easier to carry out than a "try to find a web site that accepts third-party URLs for XHR requests and has access to the 'protected' resources" scheme. Server-to-server attacks would not care about Access-Control-Allow-Origin limitations either (indeed might just use the value as a source of information when implementing the attack). 

An {anonymous:true} flag in A's JS code is simply the wrong place to attempt to fix any such vulnerabilities. We pay implementation complexity and gain, IMHO, no protection.

Finally, I believe it's going to be virtually impossible to teach developers how to use the anonymous flag, if our understanding of realistic (ab)use cases is lacking.

Hallvord R. M. Steen
Core tester, Opera Software

Received on Tuesday, 14 May 2013 10:46:47 UTC