Re: Accountability in AC4CSR

Ian Hickson wrote:
> On Tue, 12 Feb 2008, Close, Tyler J. wrote:
>   
>> +Framing the Referer+
>>
>> For this scenario:
>>
>> resource host: acting faithfully
>> third-party script: not involved
>> user: acting dishonestly
>>
>> In this scenario, the user is the attacker and seeks to cause changes to 
>> the resource that the resource host will blame on a third-party chosen 
>> by the user.
>>
>> The user sends a request like:
>>
>> POST /spendMoney HTTP/1.1
>> Host: honestBank.com
>> Referer-Root: https://honestBlogger.com
>> Cookie: "user's authentication tokens"
>> Content-Type: application/json
>>
>> {
>>   "recipient": "identifier for user's accomplice",
>>   "amount": "20 bucks"
>> }
>>
>> The user later claims he never consented to spending this money and 
>> should be reimbursed by honestBlogger.com. The user's accomplice has 
>> already absconded with the cash. The honestBank.com site can't know 
>> whether the POST request was sent by a dishonest user, or by an honest 
>> user defrauded by a dishonest script from honestBlogger.com (see the 
>> next attack).
>>     
>
> Not including cookies or authentication information wouldn't help here, as 
> you would just end up having to include authentication using some other 
> mechanism.
>
> Not including the Referer-Root header wouldn't help either, since in this 
> case the header isn't trustworthy in the first place.
>
> The correct way of implementing the above safely on the server side is to 
> have the server (what you call the "third party" side) sign each request 
> before sending it to what you call the "resource host".
>
> This is equivalent to what happens today on sites that want to seriously 
> address XSRF risks -- they sign each request, and requests that aren't 
> signed get rejected. Servers in such situations can ignore Referer headers 
> altogether. 
This is what schemes such as OAuth (and proprietary equivalents such as 
AOL's OpenAuth) do today.  They sign the request  and include things 
such as a timestamp and/or nonce to help mitigate replay attacks.  They 
also explicitly identify the signer.

My point here is just that there are existing mechanisms that are 
already deployed in the field to deal with these attacks.  And to plead, 
as a side note, not to block the use of such mechanisms for AC4CSR...

John