Re: [CORS] Security models and confusion about credentials

Hi Brad,

I'm not proposing any normative or behavioral changes to CORS. I'm strictly
interested feedback to my two suggestions, particularly
`Access-Control-Allow-Credentials`. Right now I'm crafting a few examples
on how a common mis-implementation may be attacked to leak CSRF tokens or
gain access to an account (depending on how the application is crafted),
which I plan to post.

While I am interested in abandoning same-origin privileges altogether
(which is already the case for many things that aren't Web browsers,
including my implementation), for the meantime, I'm only pointing it out to
make sure CORS doesn't interfere with adoption of more secure authorization
schemes - this use-case seems to have very little if any attention paid to
it, and it is an issue that is relevant here: CORS helps secure the Web by
enabling alternatives to e.g. JSONP, something which relies on a particular
same-origin behavior, and as such is very prone to attack. My two specific
suggestions are trying to make sure that people don't accidentally fall
prone to the same attacks that JSONP is vulnerable to.

CORS is of personal interest because I have two applications, one
implementing CORS as a user agent (not a Web browser though, but one that
doesn't follow HTTP's origin model), and an application designed to enable
easy and secure use of CORS, which seems to be the biggest problem facing
it so far (as pointed out by Anne and TBL, among others).

Thanks very much for your feedback, it's been very helpful. I will likely
be using CSP in my Web application sometime soon.

Austin.


On Tue, Sep 17, 2013 at 1:08 PM, Brad Hill <hillbrad@gmail.com> wrote:

> Austin,
>
>    The Web is the way it is.  It works the way it works.  It has worked
> that way for a long time and been quite successful.  It was designed to be
> deeply connected, has grown organically in ways that its original design
> never could have anticipated, and there are some consequences for security
> and privacy that have come with that deep interconnection.   But it's not
> as clear as you claim that these are vulnerabilities that need to be fixed,
> regardless of the consequences to existing content and applications.
>  There's an equally valid perspective that resources that place themselves
> into the HTTP and browser ecosystem must be aware of how it works and how
> to operate securely according to its rules.
>
>   If those rules doesn't work for your particular application, I don't
> think you'll find anyone on this list who will discourage you from
> experimenting with different ways of doing things that may be subtly or
> radically different from the current security model of the Web.
>
>   But if you're proposing changes that will break huge swaths of the
> existing web and require radical re-tooling of the fundamental security
> model of browsers, cramming them at the last minute into a specification
> that's been stable for years isn't the right approach.  The right approach
> is to experiment, to demonstrate that your model is valuable and viable,
> and establish a consensus in the industry that the benefits of adopting
> your model outweigh the costs.
>
>   Write a plugin or fork a browser and do some research.  Learn,
> understand and be able to clearly explain the impact and consequences of
> your proposal, and the full scope of the changes necessary to make it
> really work.  Think hard about how it might be possible to adopt it
> incrementally without breaking existing content.  And in the meantime, if
> you just want to write your application, I will again suggest that you look
> into the sandbox directive of Content Security Policy, implemented in all
> major browsers, which allows you to place every resource in a unique origin
> and in so doing, "opt out" of the origin security model.
>
> Sincerely,
>
> Brad Hill
>
>
>
>
>
> On Fri, Sep 13, 2013 at 6:55 PM, Austin William Wright <aaa@bzfx.net>wrote:
>
>> 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.
>>
>
>