Ian McKellar has a blog post entitled Insecurity is Ruby on Rails Best Practice where he points out that by default the Ruby on Rails framework makes sites vulnerable to a certain class of exploits. Specifically, he discusses the vulnerabilities in two Ruby on Rails applications, 37 Signals Highrise and Magnolia, then proposes solutions. He writes
Cross Site Request Forgery
CSRF is the new bad guy in web application security. Everyone has
worked out how to protect their SQL database from malicious input, and
RoR saves you from ever having to worry about this. Cross site
scripting attacks are dying and the web community even managed to nip
most JSON data leaks in the bud.
Cross Site Request Forgery is very simple. A malicious site asks the
user's browser to carry out an action on a site that the user has an
active session on and the victim site carries out that action believing
that the user intended that action to occur. In other words the problem
arises when a web application relies purely on session cookies to
There aren't any good easy solutions to this. A first step is to do
referrer checking on every request and block GET requests in form
actions. Simply checking the domain on the referrer may not be enough
security if there's a chance that HTML could be posted somewhere in the
domain by an attacker the application would be vulnerable again.
Ideally we want a shared secret between the HTML that contains the form
and the rails code in the action. We don't want this to be accessible
other platforms like Drupal
achieve this is by inserting a hidden form field into every form that's
generated that contains a secret token, either unique to the current
user's current session or (for the more paranoid) also unique to the
action. The action then has to check that the hidden token is correct
before allowing processing to continue.
Incidents of Cross Site Request Forgery have become more popular with the rise of AJAX and this is likely to become as endemic as SQL injection attacks until the majority of Web frameworks take this into account in their out of the box experience.
At Microsoft, the Web teams at MSN and Windows Live have given the folks in Developer Division the virtue of their experience building Web apps which has helped in making sure our Web frameworks like ASP.NET Ajax (formerly codenamed Atlas) avoid this issue in their default configuration. Scott Guthrie outlines the safeguards against this class of issues in his post
JSON Hijacking and How ASP.NET AJAX 1.0 Avoids these Attacks where he writes
ASP.NET AJAX 1.0 includes a number of default settings and built-in features that prevent it from being susceptible to these types of JSON hijacking attacks.
ASP.NET AJAX 1.0 by default only allows the HTTP POST verb to be used when invoking web methods using JSON, which means you can't inadvertently allow browsers to invoke methods via HTTP GET.
These mitigations would solve the issues that Ian McKellar pointed out in 37 Signals Highrise and Magnolia because HTML forms hosted on a malicious site cannot set the
Content-Type header so that exploit is blocked. However neither this approach nor referrer checking to see if the requests come from your domain is enough if the malicious party finds a way to upload HTML or script onto your site.
To completely mitigate against this attack, the shared secret approach is most secure and is what is used by most large websites. In this approach each page that can submit a request has a canary value (i.e. hidden form key) which must be returned with the request. If the form key is not provided, is invalid or expired then the request fails. This functionality is provided out of the box in ASP.NET by setting the Page.ViewStateUserKey property. Unfortunately, this feature is not on by default. On the positive side, it is a simple one line code change to get this functionality which needs to be rolled by hand on a number of other Web platforms today.