RE: [CORS] Security models and confusion about credentials

Austin,

  CORS doesn’t speak at all to same origin behavior.  You’ll find that CORS is the least of your worries if you’re trying to build an app that doesn’t allow resources from the same origin to interact via side channels like (but hardly limited to) script, as no part of common user agents attempts to enforce this as a security boundary.

There isn’t, unfortunately, a good normative treatment from the W3C I’m aware of that defines “the Web security model”, but Michal Zalewski’s “The Tangled Web” or its predecessor, The Browser Security Handbook (https://code.google.com/p/browsersec/wiki/Main) would be some reading I’d suggest.

If you really want to explore alternate security architectures in standard user agents without accepting the Same Origin Policy, I think the only thing on offer would be to make use of the sandbox directive of CSP (http://www.w3.org/TR/CSP/#sandbox-optional) for every resource, which places them into a unique origin (effectively giving them a unique security principal).

Good luck.

-Brad

From: Austin William Wright [mailto:aaa@bzfx.net]
Sent: Tuesday, September 03, 2013 11:01 AM
To: Anne van Kesteren
Cc: WebAppSec WG
Subject: Re: [CORS] Security models and confusion about credentials


On Tue, Sep 3, 2013 at 2:54 AM, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
We've had this discussion before. See
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/thread.html#msg1215

and elsewhere. I'm not particularly interested in going through that
again. The web has cookies, CORS can deal with user credentials, it
can also deal without user credentials. The former requires way more
opt-in.

Searching the mailing lists didn't turn up anything very interesting - this discussion is relevant, but doesn't get around to the concerns I'm talking about.

I'm interested in replacing the origin model completely, and to the extent that origins must be used, I haven't seen any description of secure same-origin behavior. There has been some discussion of superseding the origin model, but no specific proposals with a name.

The only secure behavior is to never send credentials in a request that's going to be rendered or read by anything except the user agent. CORS contains no straightforward description of how to accomplish this.

How does the Web having cookies impact this?


On Sun, Sep 1, 2013 at 9:46 PM, Austin William Wright <aaa@bzfx.net<mailto:aaa@bzfx.net>> wrote:
> In four places, the report says:
>
>     Note: [CORS] The string "*" cannot be used for a resource that supports
> credentials.
>
> One, this note is only informative, where is this normatively specified?
In the user agent section.

It might help to read http://fetch.spec.whatwg.org/ which is a revised
take on CORS (its replacement) and fetching resources on the web in
general.

I still can't find the step that says "Set the `omit credentials flag` to true." The flag appears to be a user-agent provided argument. What provides the guarantee that no script will make a request with credentials, unless specifically requested?


> Two, is there some guarantee that a CORS-compliant user-agent will not send
> credentials with a request that will be readable?
It won't expose the response unless the response opted in. For some
definition of "readable". Note that e.g. without CORS you can display
an image from a different origin with credentials included, which does
expose some information (existence, height/width).

If the Web specifications were consistent, CORS would be required in order to load a cross-origin image with credentials. The image may be defined externally, but the rendered resource comprises in part of it, and should be readable by the resource as such.

That you can't read the contents of a loaded image, because the image may be requested with credentials, might work, but is something of a hack, which depends on height/width not (typically) containing confidential data. I wouldn't make this assumption. For instance, you might be able to load an image and examine its size to determine if a user is logged into a particular website or not. If that website is for a secret society, this could be bad.


> Three, I desire to expose all the HTTP headers to XMLHttpRequest and other
> APIs (on the basis that if I didn't want the user-agent to know about it, I
> wouldn't send the header). Is there some reason this might be dangerous? And
> is there some method of specifying this? I cannot be sure of which headers,
> exactly, will be sent with the actual request, when processing the
> pre-flight request. It seems like the solution is to list every single
> header I could possibly send as `Access-Control-Expose-Headers`, which seems
> excessive.
Excessive it has to be. We don't want people to accidentally expose
debug headers.

Is there an example of an attack?

Careful may be a good policy, but on the other hand I don't believe the specs should be responsible for people implementing non-standard headers that leak sensitive information, especially when those headers are visible to user agents anyways. What could a malicious resource do that a user agent wouldn't?

I noted that the option to mark a response as readable by a script, when the request includes credentials, is almost always insecure - it's a certainty if the user credentials can be used to modify data. A header like `Access-Control-Expose-Headers: *` is far less likely to be insecure. So why is the former permitted and the latter not?