The recently publicised Ruby on Rails SQL injection vulnerability is really down to a single issue: many developers are not aware of hardening their code. The article linked at the bottom of this post showcases both issues.

Lack of awareness of Rails secret token file

This file, as its name implies, is where the token used to further protect user sessions is configured. Inquisitive people would spot such a file quickly and ensure they won’t expose it where it shouldn’t be. Apparently many are blissfully ignorant of this file and they just push everything to Github.

The First rule of SQL injection 101

If you examine how SQL injection is achieved, it’s just a very basic mistake that has been known forever: unchecked input parameters.

A security aware developer, writing this single line of code would wonder what could happen if the input parameter were to be manipulated, and whether that were even possible. And that is the second awareness awareness that would have caught the issue.

A type safe programming language would have protected against this vulnerability too. An id is typically an auto-incremented database field, a number. So, any attempt to pass a spurious SQL string in such function would have been rejected by the type safe code. Ruby isn’t type safe.

Here is the blog that apparently uncovered this recent vulnerability: let me github that for you.