>>> 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.
Indeed.
> 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
