4 ms·
This isn't a problem if you check the type of data you get from a user before you use it. You should be doing that anyway. The article says a work-around is t
by webjprgm 14y ago
This isn't a problem if you check the type of data you get from a user before you use it. You should be doing that anyway.
The article says a work-around is to use .to_s or .to_i on user input. My standard practice is to cast to int for all IDs I get externally (in PHP too). Some projects I work on go so far as to validate type and data ranges of every argument passed in. Those applications would therefore not be vulnerable even though Rails itself is.
- colinsidoti 14y ago"You should be doing that anyway." A huge selling point of Rails, other web frameworks, and ORMs in general, is that you don't have to be doing these checks. You can push the query through without concern of SQL injection, and handle the failure case there. This is convenient because you often have to handle that failure case anyway. Rails' own "Getting Started" guide uses this technique because it's assumed to be secure: http://guides.rubyonrails.org/getting_started.html#showing-an-individual-post http://guides.rubyonrails.org/getting_started.html#showing-a... We know you can "break" the application by tampering with IDs, but you shouldn't be able to pose a security threat. Validating type and data ranges is common with things like dropdowns, where you need to ensure an actual option was selected. This is a very common security flaw, and it's definitely good practice to be checking (especially when it leads to adding/updating database rows).
- Yahivin 14y agoThe getting started guide does not use that technique. It uses `Post.find(parms[:id])` The vulnerability is in `Post.find_by_id(params[:id])` and any other `find_by_*` dynamic finders.