[tahoe-dev] solve CSRF by making references unforgeable, not unshareable
zooko
zooko at zooko.com
Tue Mar 24 19:32:19 PDT 2009
Dear people of tahoe-dev and cap-talk:
Due to a query from Mark Miller about our experiences with CSRF and
"webkey"-style capabilities-in-URLs, I updated the web page about
CSRF on the http://hacktahoe.org site:
http://hacktahoe.org/csrf.html
It begins like this:
There is a general principle here which deserves to be more widely
appreciated. A CSRF attack looks, under the hood, a lot like sharing.
(The difference is that the sharer intends to harm the receiver.)
Compare Figure 1 -- CSRF attack and Figure 2 -- sharing.
bad guy victim site
.------. message .-----. authority .-----.
| >:-} | ----------> | :-| | ========> | ... |
'------' '-----' '-----'
Figure 1 -- CSRF attack: the bad guy presents a message (such as a
form or a hyperlink or a page with Javascript on it) to the victim
who sends a request -- an authority-wielding message -- to the site
which has an effect. The victim already had the authority to do that
thing, such as to delete her private files, but she didn't realize
what the form or hyperlink was going to do when she clicked on it.
friend friend site
.------. message .-----. authority .-----.
| :-) | ----------> | :-) | ========> | ... |
'------' '-----' '-----'
Figure 2 -- sharing: a friend sends a message (containing something
such as a form or a hyperlink or Javascript) to another friend which
does something on the site when she clicks on it.
This insight leads us to propose the following aphorism: Solve CSRF
attacks by making references unforgeable, not by making them
unshareable.
More information about the tahoe-dev
mailing list