Re: [CORS] Security models and confusion about credentials

On Tue, Sep 3, 2013 at 11:53 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Sep 3, 2013 at 7:36 PM, Austin William Wright <aaa@bzfx.net>
> wrote:
> > 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.)
>
> It won't work because implementations already do this, sites use it,
> and we're not going to break them.
>

I mean writing a section in Security Concerns for servers/resource authors,
on what a server should to do to ensure that clients cannot make requests
with credentials (regardless of origin). Or to the extent they can, that
the request isn't processed by the server and the response be unreadable by
the script.

But on the topic of user agents, the solution isn't any different than any
other security hole. It doesn't matter how long the hole has been around,
you _fix it_. Security is more important than reverse compatibility,
efficiency, or any other concern.


>
> Aside: The web security model is defined by HTML:
> http://www.whatwg.org/C Extracting it from there requires lengthy
> detailed reading though. This document contains a high-level overview
> of some of the concepts and legacy artifacts:
> https://tools.ietf.org/html/rfc6454


RFC 6454 isn't marked as obsolete? And I'm purposefully keeping the
discussion of particular technologies as generic as possible. None of this
discussion depends on HTML or Web browsers: I'm not just using HTML, but
JSON Hyper-Schema and scripting embedded in RDF; and I'm not just using Web
browsers, but other user agents like highly coupled HTTP clients and
spiders alike, that consume specific media types (e.g. "JSON-formatted
GitHub commit data, version 3") and self-describing, generic media types
(JSON and RDF as mentioned above), respectively. What an HTML specification
says to these technologies is out-of-scope. And try as it might, I don't
believe HTML can normatively define scripting-related concerns any more
than it could re-define HTTP (it doesn't appear that's in-scope anyways, by
the HTML WG charter).