Re: Cross Site Request Forgery and GET (ACTION-274)

Granting that naive users won't know to do this, and even sophisticated 
users can easily forget: to what extent can individuals protect themselves 
by logging off from one site before visiting another.  In the Netflix 
case, am I right that the vulnerability came because a user visited 
Netflix, resulting in a cookie for that access, then without logging off 
visited a malicious site that used (for example) a script to post an 
address change or queue update to Netflix?  Would this have worked if the 
user carefully logged off from Netflix before moving on to the next site?

Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Thomas Roessler <tlr@w3.org>
Sent by: www-tag-request@w3.org
06/03/2009 01:28 PM
 
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Cross Site Request Forgery and GET (ACTION-274)


Hello,

Dan Connolly asked me to give a quick summary about CSRF.  From the record 
of the 28 May meeting:

  http://lists.w3.org/Archives/Public/www-tag/2009May/0123.html

... I gather that the main question was specifically about the interaction 
between safe and unsafe methods here.

There are really two angles to this point:

1. It is really easy to write applications that simply do not distinguish 
between GET and POST.  See this FAQ for some examples:

  http://www.cgisecurity.com/csrf-faq.html

The result are Web applications that use POST for their own purposes, but 
actually perform the same operation when they encounter a GET request. 
These kinds of application errors can be exploited through relatively easy 
means, e.g., causing a GET request from some inline content (img tags are 
popular).

2. HTML forms expose a submit method in JavaScript.  Since forms can be 
submitted cross-origin, an attacker can cause a browser to send any 
form-generated POST request to any origin, without the user noticing. 
Note, however, that such requests are sent blindly:  The attacker will, 
for example, not know any personalized information that the web 
application in question might have sent to the user; the attacker also 
won't see the site's response to the request.  That's at the basis of 
using a nonce as a defense technique; in this case, any application that 
can cause form actions through POST has to prove that it can read 
information form the site.

Happy to discuss more,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Thursday, 4 June 2009 22:35:13 UTC