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
