Thomas Roessler wrote:
On 2008-06-13 16:56:16 -0700, Jonas Sicking wrote:
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.
As I said in [1], I think this is pointless.
- Requests without cookies can be sent by the attacker anyway (but
from a different IP address); there is little to no point in
having a separate mechanism to authorize these requests coming
from the client.
We unfortunately do have to authorize requests even without sending
cookies. This is to protect content behind firewalls. This is
unfortunate but I don't see a way around this.
- Any arguments that apply to the authorization mechanism as
specified now (e.g., that people don't understand what they are
doing, and will therefore write bad policies) will likewise apply
to an authorization mechanism that is specific to requests with
ambient authorization. (Wait, that's where we started out with
this!)
Yes, but that should be a smaller set of people since the people that
only want to share public data won't have to worry. So the result should
be fewer exploitable sites.
Sharing private data is always going to be tricky. Not least since the
site has to get the user in the loop and ask him/her before sharing the
data with unknown third parties.
Just don't do this.
1. http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0083.html
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.
I agree with Maciej that this is highly distasteful. Don't do this.
I'm fine with removing the nested scheme and using an out-of-band
boolean flag instead.
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.
So we're now having two levels of authorizations -- some things can
be done from the PI, and some can only be done from headers?
Yes. The PI pretty much only makes sense for static files anyway, which
usually contain public data.
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.
Additional inconsistency strikes me as even more of a mis-feature.
Don't do this.
It significantly reduces the security risk of having the PI in the spec.
That sounds like a good thing to me.
/ Jonas
