Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
Well, let's first be clear about the setup here, to use the PUT example:
+---------------+ +------------------+
| Attacker |-----------------| Compromised site |
+---------------+ +------------------+
| / |
[Can't PUT] +->> trusts >>+ |
| / \ |
+---------------+ +------------------+
| Victim server |<---[Can PUT!]---| Privileged User |
+---------------+ +------------------+
So the victim server would already be configured to tell Privileged User
and Attacker apart, otherwise the attacker could PUT directly and would
not care about cross site requests. It can't be enough to compromise the
other site as otherwise the attacker could PUT directly aswell (e.g. the
site stores username and password in a cookie, attacker reads out cookie
and uses them to authenticate with the victim server)
So first off I think a lot of sites are going to "trust" *, so there is
no need to compromise a site, just set up your own.
Second, even if you compromise a site, you can only steal the users
cookies for *that* site, not the cookies for the victim server.
Quite correct, but you misread if you think I wrote anything to the con-
trary. You also seem to have missed my request for examples for headers
that dramatically alter the server behavior and server setups where it'd
be difficult to prevent the problem you are concerned about. Sharing the
examples would make it easier to see why your proposal must be adopted,
or come up with an alternative.
I don't have any specific known headers in mind, no. If the problem was
simply a few known dangerous headers we could simply black-list those.
My concern is that there might be servers, or server addons that add
support for features that we or the server admin isn't thinking of. For
example any of the following features would be very dangerous:
* Stiching two resources together. The header would supply a second URI
that is concatenated at the end of for a GET request.
* Specifying that a specific header should be added to the reply.
* Preprocessing of the reponse. For example preprocessing using an XSLT
transform that could insert a Access-Control processing instruction.
I'm sure the list is longer, these were the things I could think of off
the top of my head.
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. The
implementation would stop parsing at the <foo> tag and let the full
response through. The XHR object would fail to parse the reply as a
proper full XML document, however the full text would still be available
through the .responseText property.
If a person from the "security group" then visited the attackers
website, the website would be able to read all the "security private"
comments after the attackers comment in the bug.
This is easy enough to fix for the Range header. All we need to do is to
say that Access-Control PIs should not be honored if a Range header is
specified.
However we could obviously not apply the same fix if other custom
headers have the same problem.
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.
/ Jonas
