RE: Accountability in AC4CSR

Ian Hickson wrote:
> Could you elaborate on exactly what situation you are envisaging here,
> using concrete examples?

I have been discussing two distinct attack scenarios in this thread. Let's call them: "Framing the Referer" and "Robbing the user". I distinguish 3 different parties in these scenarios: the resource host, the user and the third-party script. For both scenarios, I am assuming the web user agent is faithfully acting on the user's behalf, and so need not be considered as an indepedent entity with its own interests. The user and the web user agent can be thought of as a single entity.

+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).

+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.

The third-party script sends exactly the same HTTP POST request shown in "Framing the Referer". 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.

These two attacks reveal two distinct problems with the AC4CSR protocol. In "Framing the Referer", we see the danger of relying on information that cannot be verified. In "Robbing the user", we see the danger in allowing a third-party site to wield the user's authority, represented in the form of cookies, without the user's consent.

--Tyler

Received on Tuesday, 12 February 2008 02:48:43 UTC