Re: [CORS] Security models and confusion about credentials

On Tue, Sep 3, 2013 at 7:01 PM, Austin William Wright <aaa@bzfx.net> wrote:
> 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?

The flag is set by APIs that use CORS, such as XMLHttpRequest and <script>.


>> 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.

Of course, but the web was not thought through. It grew organically,
with many flaws.


> 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.

Yes, this is a known issue that cannot be fixed. Well, I once designed
something that could maybe fix this: http://www.w3.org/TR/from-origin/
But nobody was really interested.

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

Share the information with evil.com. The idea here is that evil.com
cannot be trusted, but the user agent as well as the user's computer
is trusted. If either of those are compromised, the user is already
lost.


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

I guess there's disagreement over what is insecure and what is.
Unfortunately I don't recall all the rationale here. We might be able
to add Access-Control-Expose-Headers in due course if it's a
significant problem in practice. So far, what seems to be holding CORS
back is it using headers at all. People don't really know how to set
that up...


-- 
http://annevankesteren.nl/

Received on Tuesday, 3 September 2013 19:01:39 UTC