Re: [CORS] Security models and confusion about credentials

For some reason, I was under the impression that CORS was still necessary
to perform non-simple requests on the same origin, e.g. PUT, or using the
Authorization header. The testing I was doing in Chromium was making a
pre-flight request for my requests, though now it doesn't seem to be doing
so. I thought that was just a bug with the inspector/debugger, but maybe I
wasn't actually making the request to the same origin.

Some word on credentials (regardless of origin) would still be relevant for
Security Considerations. Particularly, how resources can require that
sending of credentials be disabled. For instance, perhaps you could forbid
requests containing both Origin and Cookie. (Is there any reason this
wouldn't work? I don't like the sound of it, as it depends on the user
agent sending the Origin header.)


On Tue, Sep 3, 2013 at 11:10 AM, Hill, Brad <bhill@paypal-inc.com> wrote:

>  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>
> 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>
> 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?****
>
> ** **
>