Re: [CORS] Security models and confusion about credentials

On Fri, Sep 6, 2013 at 3:47 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> It's not a security hole.
>

It may not be in the scope of CORS or WebAppSec to fix for most cases, but
I nonetheless do describe a security hole, that potentially sensitive
information may be leaked. We already identified some:

1) Height/width leaks in images, being used to determine the status of a
user-agent on a particular origin (If a user is logged in, if they have
items in their shopping cart, etc). When this leakage involved testing the
colors of links to determine if they're visited or not, it was deemed a
security hole and fixed quickly.
2) Numerous related problems with script tags. (Particularly the numerous
attacks on JSONP.)
3) No differentiation between requests to be handled by the user-agent
(which should include credentials), and requests handled by a third party
script (which are not part of the user agent, and therefore must not
include user agent credentials).
4) User agents not honoring the response Content-Type of a script. This may
be used to read third party data with credentials, even when the response
explicitly marks the content as not readable or executable. We formerly saw
this issue in Firefox with JSON being read as ECMAScript, and now, Turtle
and SPARQL are potentially vulnerable.

Similar leaks in TLS or link-coloring have been hastily fixed and rolled
out, despite existing for years. But leaks from other HTML elements are
acceptable? I'm trying to figure out why it is, that third parties knowing
that you are logged into https://SuperSecrets.example/ is acceptable, but
knowing that you merely followed a link to it isn't.

I'm not sure if, at this point, there is anything CORS can do about this.
Possibly, it seems relevant that it could grant permission for a
cross-origin image to become readable by a script.

Overall, the course of action here would be to raise an issue with the
appropriate WG.

The HTML
> Standard defines the security model of the web, irrespective of what
> scope or charters have to say about it. As for the HTML WG, it's
> mostly in the business of copy-and-pasting the HTML Standard.
>

Since when? The HTML spec can't just declare itself the authority over
something that's not HTML, especially one that's the realm of another
standard. This is important because HTML is merely one use case of the Web.
It cannot fathom all the things that I use it for - does what I wrote about
user agents make sense? The language you link to just doesn't make sense
here, the Semantic Web simply has no origin: even if I _wanted_ to, I can't
apply what HTML says. This "bearer security model" is created out of
necessity, not merely the observation that the origin model is broken.

Because of this, what I'm asking of CORS is that--where possible--language
be adopted explaining which features must be adopted by applications to
make them secure. I don't see any language in "Security Concerns" that
explains how dangerous the Access-Control-Allow-Credentials header is! The
report really needs to mention that Access-Control-Allow-Credentials will
expose CSRF tokens, if any, to untrusted applications.

CORS should also mention, under "Security Concerns", the necessary
requirements of an application so that CSRF tokens don't get leaked to
resource scripts. If I understand the report correctly, this means
applications must only ask user agents to store credentials containing a
"user-agents-only" flag, which (when present) means that, when there's an
indication that the request is handled by a resource script instead of the
user agent (like the presence of an Origin header), the server will return
an error and refuse to process the request. This user-agents-only flag
might be implicit of all Cookie headers, if Web browsers are the only users
of cookies in an application. Does this sound about correct?

Are these two notes something that can be added?

Austin.