Most of "Insecure Interactions" is still a serious issue with Rails. It's very easy to wind up with XSS, SQL Injection, and XSRF in Rails apps; to avoid them, you not only have to be using Rails, but using Rails right.
The simple cases for all of these are automatically eliminated with Rails; for instance, searching for "O'Malley" in a search box isn't going to trigger SQLi. But somewhere in any large-ish application, someone is going to do a custom join or a complicated conditional, and that brings SQL input validation along to the party.
Same deal with XSS. Rails gets rid of XSS, if you (a) default to h() style filtering and never override it, or (b) rigorously audit your code. But most large applications have code paths where something other than Erb is generating HTML (for instance, some library may use HAML to generate a report), and those code paths often escape output filtering.
I'm not trying to stick up for the CWE 25; I think most of these lists are pretty silly. What they're really intended to do is to help enterprise programmers feel like they have their minds wrapped around the software security problem, so that they have a place to start. Other lists, particularly the (equally outmoded) OWASP Top 10, have succeeded spectacularly at that.
Comments
Most of "Insecure Interactions" is still a serious issue with Rails. It's very easy to wind up with XSS, SQL Injection, and XSRF in Rails apps; to avoid them, you not only have to be using Rails, but using Rails right.
The simple cases for all of these are automatically eliminated with Rails; for instance, searching for "O'Malley" in a search box isn't going to trigger SQLi. But somewhere in any large-ish application, someone is going to do a custom join or a complicated conditional, and that brings SQL input validation along to the party.
Same deal with XSS. Rails gets rid of XSS, if you (a) default to h() style filtering and never override it, or (b) rigorously audit your code. But most large applications have code paths where something other than Erb is generating HTML (for instance, some library may use HAML to generate a report), and those code paths often escape output filtering.
I'm not trying to stick up for the CWE 25; I think most of these lists are pretty silly. What they're really intended to do is to help enterprise programmers feel like they have their minds wrapped around the software security problem, so that they have a place to start. Other lists, particularly the (equally outmoded) OWASP Top 10, have succeeded spectacularly at that.