Ruby on Rails Security Project

Exploring the Security of Rails and friends.

Ruby on Rails Security Project header image 2
← Ruby regular expression fun Cross-Site Scripting (User Agent Injection) Attack Methods →

Cross Site Request Forgery (CSRF) and GET & POST

April 20th, 2007 · 4 Comments

The W3C advises when to use GET requests:

Use GET if:

  • The interaction is more like a question (i.e., it is a safe operation such as a query,read operation, or lookup).

Use POST if:

  • The interaction is more like an order, or
  • The interaction changes the state of the resource in a way that the user would perceive(e.g., a subscription to a service), or
  • The user be held accountable for the results of the interaction.

 

It is a widespread belief that choosing POST over GET requests for actions changing the state can prevent attacks known as session riding or Cross Site Reference (or Request) Forgery (CSRF). An attacker can prepare a special inconspicuous link, which points to an action that changes the state of the web application, and put it in an email or on a website. If the user is logged in to the web application and clicks on that link, the browser will automatically send the users session identifer, and the attacker can place an order, change the password et cetera in the name of the user. There are also forms of this attack where the URL of an image on a web site is this prepared link and thus the action will be executed automatically when the victim views the web site.

This class of attacks cannot be avoided by accepting only POST for some requests. Even POST requests can be sent automatically or by a click on a link. Include a security token in each request, as the security extensions against session riding do, to avoid these attacks. Another, better, plugin to include a security token in forms is the csrf_killer.

 

In order not to allow state changes in a GET request, you can use the verify method in the controller:

verify :method => :post, :only => [ :remove_tasklist ],
:redirect_to => { :action => :list }

Tags: Rails

4 responses so far ↓

  • 1 Chris Shiflett // Apr 20, 2007 at 6:41

    Here’s an example that forges a POST request:

    http://shiflett.org/blog/2007/mar/my-amazon-anniversary

    I don’t think there are too many people who truly believe that requiring POST prevents CSRF. On the flip side, there are a growing number of cases where requests that don’t perform actions are being forged for the purpose of information disclosure.

    Glad to see a new web application security blog. Best of luck. :-)

  • 2 Terabanitoss // May 6, 2007 at 2:31

    Hello
    You are The Best!!!
    G’night

  • 3 Josh // Sep 4, 2007 at 9:37

    Thanks for this post - I recently discovered that it was frowned upon to use a GET when it should be a POST, but in an app which requires authentication I couldn’t see why there could be a problem.

  • 4 Heiko // Sep 5, 2007 at 8:45

    GET/POST is not a security problem (since CSRF can be done with both), but a standard as you can read at the W3C. If you authenticate people you’ll most likely be giving them a cookie, that makes it prone to CSRF…use csrf against it.

Leave a Comment