TL;DR
This post will explain how to check your Ruby on Rails code base against sql injections [Wikipedia].
After you have read Wikipedia source link about sql injections, you are ready to proceed. It is important to state that Ruby on Rails offers one of the best (if not the best framework) out of the box sql injection protection.
But sometimes, developer needs to be able to override this protection for some “Twin Peaks” feature requests. In that case, even experienced Rails developer could make sql injection attack possible. On the other spectrum, if your company can only afford junior Rails developers, this check is a must.
Here is how you should hunt such protection overrides. First, head to Rails SQL Injection site. This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. You will use this site as a reference.
Open your terminal, go to root folder of Rails project repository, and use this cmd:
grep -H -r 'search for activerecord method' * | less
You need to replace search term with active record method name. Here you need to be creative in order to filter out results that do not represent active record method.
Here is the punch line:
Never, ever, trust the user input!
Which means that user input must not be directly used in active record methods. Again, refer to Rails SQL injection site in order to learn how to recognize code that is prone to sql injection.
Wait, but I am using Windows that do not have grep! Well, Google is your friend, there is a number of open source tools that will help you.
We also need to check all custom SQL queries using command:
grep -H -r 'execute' * | less grep -H -r 'params\[' * | less
Same as for the active record methods, user input must not be directly used in custom SQL queries.
p.s. Twin Peaks feature request makes developer to have experience very similar to experience of watching Twin Peaks: “The Return” [source].
