Opting in to cookies - proposal version 3

Hi All,

Most of the feedback I got from my previous proposal was in regards to 
the nested uri scheme solution, which wasn't really a critical part of 
the proposal. So here is an alternative proposal which doesn't use the 
nested schemes but rather a separate flag.

Only the second paragraph in the proposal is changed (the one starting 
with "When the resource is loaded"), the rest is exactly the same as before.

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 XMLHttpRequest the "with credentials" 
flag is set to the value of a new 'loadPrivateData' boolean attribute on 
the XHR object. This attribute has to be set before the call to the 
open() method, and defaults to false. When another mechanism is used to 
load the resource, such as <?xml-stylesheet?> or <?xbl?>, that loading 
mechanism defines how to set the "with credentials" flag, but the 
default behavior is to set the "with credentials" flag set 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 Thursday, 19 June 2008 00:25:40 UTC