The issues mentioned in the blog post have all been address in Rails. All Rails’ form helpers include a hidden field to protect against CSRF. You rarely have to even think about this issue anymore.

Rails also now discourages allowing GET requests when they shouldn’t be allowed.

I’m not sure what your intentions were when posting this, but the fact you posted this without mentioning the potential security problems to the sites in question raises some questions about your motives. The inflammatory title, and your ignoring rick’s comments makes it seem worse. All the best anyways, and here’s hoping CSRF becomes as easy to fix in all those other web frameworks

I aggree with Michael Koziarski’s questioning of your motives. Was this a mistake, an attempt to get on digg or do you just not like rails (do you seriously believe that the best feature of rails is it’s insecurity)? I notice this site uses Drupal so you obviously have a preference, but this wasn’t declared and as this article seems to be trying provide an objective look at CSRF attacks/security I think it would have been wise.

The content was useful, thanks, but you would have got a lot more respect from me for it if you were more up-front about your bias and motives.

And I don’t think the best feature of rails is its insecurity, nor do I think I suggested that. I suggested that the best-practice – the techniques that are used by the most prominent rails developers (such as 37signals) and are taught in the most prominent rails tutorials and books are insecure in was that are not obvious to most developers. That’s a real concern to me.

What I mean by it is that the practices that are used by the flagship rails sites and the techniques that are taught in the Rails tutorials and books are insecure. And that insecurity isn’t understood well by the community.

I am not sure if building more restrictions into Rails and other app frameworks will solve the issue of common developer carelessness – with each security-related convenience, dangers such as performing state-changing operations with GETs will seem that much farther away and that much more likely to be imappropriately placed into a seemingly innoculous method such as “show”. However, security through convenience can be effectively encourage through “easier means to do the right thing” – such as how ActiveRecord enables the programmer to prevent sql injection attacks.

In developing my first Rails app, I put logic in the controller methods to prevent state-changing GETs. I am somewhat negative about the new REST approach in 1.2 on first blush. This could be made a lot easier with a standard one-line before_filter to identify methods that can only process a POST request.

Lastly, Luke’s suggestion is interesting and should be closely considered by browser developers: “in my opinion this should be the job of the browser. the user should get a warning popup, or whatever, for every request he submits (except GETs) pointing to a different host than the current one.”

- Jamie

The reason I blame Rails and not Rails application developers is that the framework seems to abstract away and hide so many ugly details.

As for Luke’s suggestion of modifying browser behavior, I think that’s ridiculous. Perhaps I’m coming from the perspective of being a six year browser development veteran, but we’ve had the cookies web security model for ten years now. I don’t want to give it up and introduce yet-another security popup just so someone can have their “rest” URLs. Since it’s hard enough to get CSS implemented in popular browsers I wouldn’t hold my breath for this.