Re: [AC] Helping server admins not making mistakes

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

Received on Tuesday, 10 June 2008 00:59:41 UTC