Opting in to cookies - proposal

Hi All,

Since I haven't received any feedback on the various straw-men in the 
"Opting in to cookies" thread, I'll send a full proposal (wrote most of 
this yesterday, Thomas wrote some opinions on cookies this morning).

First off, as before, when I talk about "cookies" in this mail I really
mean cookies + digest auth headers + any other headers that carry the
users credentials to a site. However i'll just use the term "cookies"
for readability, and since that is on the web currently the most
common carrier of credentials.

So here goes:

When loading a resource using access-control associate the request with
a "with credentials" flag.

When the resource is loaded using an URI which starts with the string
"user-private:" set the "with credentials" flag to true. Otherwise set
it to false.

Make the following modifications to the Access Control Check Algorithm
(as described in section 5.2.1):

   Add a step before step 1 that says:

     If the "with credentials" flag is true and the HTTP header
     "Access-Control-Allow-Credentials" is missing or not set to the
     value "all" then return "fail".

   Also insert a step between step 3 and step 4 that says:

     If the "with credentials" flag is true then terminate the
     algorithm and return "fail".


When doing a Simple Cross-Site Access Request (section 5.1.3)
credentials are only sent in the request in step 3 if the "with
credentials" flag is true.

When doing a Cross-Site Access Request with Preflight (section 5.1.4)
make the following modifications:

   Entries in the access preflight result cache (section 5.1.4) are
   modified such that they include a "with credentials" field.

   Change the first paragraph in step 5 to say:

     Locate the entry in the preflight result cache where the origin
     matches the origin field value, and the current request URI is
     identical to the uri field value or starts with the uri prefix field
     value. If there is such an entry and that entry has the "with
     credentials" field value set to false, and the "with credentials"
     flag for the request is set to true, terminate the algorithm and
     return "fail". Otherwise, if an entry was located, proceed to the
     next step.

   Modify the last sentence of the paragraph in step 7 to say:

     Then append a cache entry and set the uri prefix field value for
     that entry to the policy URI, and the "with credentials" to true if
     the response contained a "Access-Control-Allow-Credentials" HTTP
     header with the value "all", or false otherwise.


The result of this is that adding the header
"Access-Control-Allow-Credentials: all" allows the server to opt in to
receiving cookies. This header is only applied to Access-Control
headers, not <?Access-Control?> PIs.

A nice side effect is that is that if there is no way to use cookies 
together with the <?Access-Control?> PI. This means that if an attacker 
somehow manages to modify the content of a reply in such a way that a 
Access-Control PI is inserted, most of the time no dangerous requests 
can be made, and no private data can be leaked. The exception is when 
the server is protected by a firewall, however that is much less common, 
especially for such servers to participate in mashups.

This should make keeping the <?Access-Control?> PI in the spec 
significantly less likely to cause exploitable servers.

/ Jonas

Received on Saturday, 14 June 2008 00:00:00 UTC