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
