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?