[cap-talk] solve CSRF by making references unforgeable, not unshareable

zooko zooko at zooko.com
Tue Mar 24 22:32:19 EDT 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 cap-talk mailing list