W3C home > Mailing lists > Public > www-tag@w3.org > June 2009

Cross Site Request Forgery and GET (ACTION-274)

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 3 Jun 2009 19:28:46 +0200
Message-Id: <EEA14D79-848D-404A-AF3E-93660D66D8F3@w3.org>
To: www-tag@w3.org
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 Wednesday, 3 June 2009 17:28:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT