Re: [CORS] Security models and confusion about credentials

On Wed, Sep 11, 2013 at 3:25 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

>
> These seem unrelated to CORS.
>

I'm trying to establish the premise for why specifications are modular and
narrow in scope, by describing my use case.

Specifically, my original post describes the flaws of the origin security
model (and most of the flaws I listed directly stem from this policy), why
the same origin policy is not suitable for many wide classes of
applications including mine, and how CORS can (in part) help
mitigate/migrate to a better, more secure, more flexible model.

My apologies for writing a lengthy essay, if you're crunched for time to
grok it.


>
> > Overall, the course of action here would be to raise an issue with the
> > appropriate WG.
>
> The things you "identified" cannot be fixed as content relies on them
> not being fixed. The way we solve them is by providing sites
> additional hooks.
>

We never settle for "insecure by default" - if either party fails to opt in
(or an attacker causes one party to opt out when they otherwise wouldn't),
the application becomes vulnerable. Again, security trumps reverse
compatibility. I provided a number of examples of features that have been
outright removed, often breaking Web applications (and rightfully so!),
because they posed security problems. I'm just not sure why the problems I
list are overlooked, while others (often more subtle) are hastily fixed.


> > Are these two notes something that can be added?
>
> How does http://www.w3.org/TR/cors/#security not cover this?
>

Can you please make specific objections to my two suggestions? I'm not sure
how I'm supposed to prove a negative... All I can say is that I've read it
thoroughly, multiple times, and I cannot find any recommendations on policy
or administration, which is the purpose of the section.

Could you point out where the report explains that
`Access-Control-Allow-Credentials` is often very dangerous, and will expose
CSRF tokens, a security feature also suggested in the same section? I mean,
there is literally nothing describing the header's possible side effects --
there's the definition of the header and that's it.

Could you point out where it describes how an application author might
ensure that scripts in untrusted resources cannot make requests with user
credentials, or if they do, that the response does not leak CSRF tokens?

If it wasn't clear, I'm not proposing changes to any normative text.

Austin.