Thomas Roessler wrote:
On 2008-06-09 17:56:17 -0700, Jonas Sicking wrote:
There is in fact already a standardized header that falls into the third
category. The "Range" header currently does allow attacks. Consider the
following:
In our bug management system anyone can write comments about any bug.
Occasionally some of these comments get marked as "security private" since
they mention security sensitive things, only people in the "security group"
can read these private comments.
An attacker could write a comment containing the text
<?Access-Control allow="*"?><foo>
The attacker would then set up a website that performed a cross-site XHR
request to the bug page with a "Range" header stating that the part starting
at the text he wrote, to the end of the document should be downloaded. The
Access-Control implementation would see a document starting with the
Access-Control PI followed by an element tag.
Interesting example. Three thoughts on it:
- There needs to be a security consideration about Range, and not
getting fooled by it -- since, frankly, the implementation you
describe above is flawed.
Which implementation is flawed?
- Can we get rid of the processing instruction already?
I would actually be ok with that. But I know others have expressed a
strong opinion to keep it.
- Wouldn't be a problem if we went for a model in which the amount
of flexibility in the client is minimal, effectively forcing
developers to put the enforcement into the server.
How is that?
However we could obviously not apply the same fix if other custom
headers have the same problem.
Indeed. But maybe the fix here is really to drop the processing
instruction and rely on headers only.
Right, but that would still only solve some of the dangerous server
features I described. It wouldn't solve a header that stitches two
resources together, or that allowed insertion of a custom header in the
reply.
Also, for what it's worth, this is a good example of when it
would be useful to be able to specify that you want to support
Access-Control, but only support it without cookies. That way we
could allow mashups with our bug database, without worrying about
leaking private comments.
If you're really concerned about private comments, you'd probably
want to actually check Access-Control-Origin on the server and set
appropriate Vary headers, no?
Yes, we could ignore the cookies whenever the Access-Control-Origin
header is sent. Or strip out the sensitive parts of the page. But that
is much harder than simply not opting in to getting cookies.
/ Jonas
