Hi All,
So I have some feedback to this proposal. I think Hixie might have
missunderstood me and while I agreed to him publishing it, it's
definitely not _from_ me.
So there are a couple of pretty big security concerns that I have with
this proposal.
1.
It introduces ordering issues. Consider the following setup; A server
contains two resources, /dir/A and /dir/B, and returns the following
replies to OPTIONS requests:
/dir/
Access-Control:allow <*> method POST
Method-Check-Policy-Path: /dir/
Method-Check-Max-Age:3600
/dir/A
Access-Control:allow <*> method POST
Method-Check-Policy-Path: /dir/
Method-Check-Max-Age:3600
/dir/B
Access-Control:deny <*> method POST
Method-Check-Max-Age:3600
If a UA now accesses resource A it would do OPTIONS requests to /dir/A
and then /dir/ and result in "allow <*> method POST" being cached as the
policy for all resources under /dir/.
If the UA then tries to do a POST to resource B this would be performed
without any OPTIONS requests. I.e. the POST to B would be successful.
However if the UA first tries to do a POST to resource B, the UA would
first do an OPTIONS request to /dir/B and then abort. I.e. the POST to B
would be unsuccessful.
2.
The current proposal means that someone that can control the responses
to a given directory can effectively control the ability to do perform
unsafe cross-site requests to any URI under that directory.
I can't really think of any bad security issues with this. It seems to
me like someone that can control a higher up directory can probably do
bad things anyway.
However it does very much increase the risk of accidentally allowing
unsafe requests to go to too many resources. I really like the fact that
the current spec makes it very explicit both when you are granting
access to responses, and when granting the ability to perform unsafe
requests.
Unfortunately these problems are not particular to this proposal. They
would hold true for any proposal that lets you configure policies both
centrally and on the resource.
/ Jonas
