RE: Accountability in AC4CSR

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. However, that doesn't reduce the use of Referer and 
Referer-Root headers in the more general case. For example, if the same 
person runs both sites, they really do trust both sites, and can thus 
trust that if someone complains that host A is doing things on host B 
without their consent, it's really the user playing tricks. Since the only 
person the user can hurt in such cases is the user himself, it's fine.


> +Robbing the user+
> 
> For this scenario:
> 
> resource host: acting faithfully
> third-party script: acting dishonestly
> user: acting honestly
> 
> In this scenario, the third party script seeks to cause changes to the 
> resource that the resource host will blame on the user.
> 
> POST /spendMoney HTTP/1.1
> Host: honestBank.com
> Referer-Root: https://honestBlogger.com
> Cookie: "user's authentication tokens"
> Content-Type: application/json
> 
> {
>   "recipient": "honestBlogger's accomplice account",
>   "amount": "20 bucks"
> }
>
> The script does so without ever consulting the user. The third-party 
> site is allowed to send cross-domain requests to the spendMoney 
> resource, but was only expected to do so with the consent of the user. 
> Most of the time, it asks for this consent, sometimes not. The 
> honestBank.com site can't know if the third-party script actually got 
> the user's consent.

Again, not including cookies doesn't change this at all -- in fact it 
would make it worse, since it would require that what you call the third 
party script have the credentials in some reusable form, and thus such 
fake requests could then later be sent totally offline without the user's 
presence at all.

Not sending the Referer-Root header here would make no difference, since 
the site is trusted anyway.

The way to safely implement this here is for the server not to trust 
untrustworthy sites, and confirm requests independently (e.g. by sending 
an e-mail asking for confirmation, and rejecting transactions that don't 
get confirmed). If both sites truly are trusted, then this can't happen.

(Note that many of the use cases for cross-site requests are actually all 
about things being done without the user's explicit consent.)


In conclusion, I don't think the spec needs to change to address these 
problems, and I don't think any of the solutions you have proposed would 
actually address them. I would be happy to see the security section 
mention these risks though, and the ways to mitigate these risks, some of 
which I've listed above.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 12 February 2008 04:40:32 UTC