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

[Sandro Magi]

Adam Barth wrote:
> How will Acme distinguish between a user who keeps the Acme home page
> open for a long time and Bob who farms out the tokens to his clients?
> Perhaps Acme's page will ping Acme for each request so Acme can
> decrement some internal counter and know when the token is supposed to
> expire?

The counter is at Google, not Acme. Acme has a Google account token.
Acme uses this Google account token to generate M Google request tokens.
Each Google request token is good for N requests tied to Acme's account.

The client uses the Google request token when communicating with Google.
When a Google request token returns an error code instead of 200 OK, the
client retrieves another Google request token from Acme.

Tokens that are used up too quickly imply a client is abusing the
service. Keeping the home page open is not a big deal, as the request
load is small when compared to a service like Bob's who must request
many tokens from a small set of IP addresses to service its own clients.

> The system you describe is much more complex than the CORS way of
> addressing this use case, and it's not clear that you've actually
> solved the use case.  You've just reduced Acme's proxying overhead by
> a factor of N (compared to zero by CORS),

Perhaps you misunderstood the degree of proxying required given you
stated above that the counter is at Acme. Bob's requests to both Google
and Acme will be orders of magnitude higher than any real user, so abuse
is easily detected and cut off.

M and N also vary depending on how the incentives align for the service;
for instance, N=infinity means Acme must explicitly revoke tokens based
on some other policy.

> and you've also reduced
> Bob's proxying overhead by a similar amount.

CORS is well-suited to this particular scenario, no argument. But the
voluntary mashup with trusted client browser is the *only* problem CORS
solves. Do you really want a solution for such an incredibly narrow
use-case? Do you have any concrete idea how many web apps map exactly to
the scenario you outlined? How about future web apps?

CORS will be misused for access control where the incentives do not
align so cleanly as in your example, and surprising vulnerabilities will
result.

For instance, if Google Finance is a very expensive service that Acme
provides its customers access to, there is more incentive for non-Acme
customers to download a client or plugin that submits forged requests
from Acme's account. The more expensive Google's service, the more
likely CORS will be abused like this. A solution using tokens cannot be
abused this way, or more accurately, the code the client is running is
immaterial to the security properties of the service.

Unique tokens are a more general solution to many problems, and while
the costs are slightly higher in this particular case, the solutions are
more flexible and robust. The confusing mishmash of so many
single-use-case access control strategies will inevitably result in many
vulnerabilities.

Sandro