The much publicised Ruby on Rails SQL Injection vulnerability is also down to a lack of developer awareness of secure coding practices.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.
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.
My Rails App, set up to run on RVM with all the right gems, kept crashing. To fix it I had to rearrange my environment, and reinstall the entire stack.
I recently spent some time struggling with an annoying problem with a Ruby on Rails app that just kept crashing. My environment is(was) Mac OSX Snow 10.6.8.
How I fixed it
- uninstall the entire stack: rails, bundler and all dependencies, gem and rvm itself,
- change my system path settings (sudo vi “/etc/paths”, put “/usr/local/bin” on top)
- restart the machine, verify that in my path “/usr/local/bin” comes before “/usr/bin”
- re-install rvm, ruby 1.9.2, gem, bundler
- verify “which ruby”, “which gem”, “which bundle”, they should all show the rubies path “~/.rvm/…rubies/…”
- install rails, redo “bundle install” in the project folder
I was having troubles getting a ruby in rails application running. This same app had been running perfectly fine before, I didn’t touch the code and others didn’t seem to have any problems running it. So it had to be something with my environment. The main change that I did was to have migrated from Ruby 1.8.7 to Ruby 1.9.2. But everyone had done that too, the app had been nicely running on 1.8.7 for me too, but not on Ruby 1.9.2. Why was this happening? Why was I the only one experiencing this problem?
Clues that led to my approach
After some googling and reading up a few blog posts, I came across this post by Yehuda Katz. I followed Yehuda’s recommendations, but that didn’t fix my issue. He’d touched upon one thing that I was sure was going to be a good lead: some gems could have been compiled with the wrong version of Ruby or native libraries. That had to be it, but where, which gems? I thought if a quick reinstall didn’t do it, something must be seriously broken. As I started removing and reinstalling the gems one by one, I kept checking the search paths, that’s how I found out that it was consistently not what I was expecting, some gems were found on /usr/bin while others were found under /usr/local/bin or in the rubies (rvm).
The only way to stop this, for me, was to remove it all, force my system to search /usr/local/bin. So I cleaned my env, adjusted the file /etc/paths to search “/usr/local/bin” before other paths.
What I’ve learned here is, as Yehuda puts it, “check your assumptions first” is probably even stronger for the DRY Ruby on Rails like environments than say Java or .NET environments. Indeed it is too tempting to think that once you’ve installed rvm, the ruby on rails stack and some nifty little gems, all following some quickly assembled and even quicker read blog postings, that everything would be fine from there. And that’s the wrong assumption that one needs to challenge.
Installing rvm, instructing it to default to another ruby version is not all there is to it. One needs to ensure that the entire stack has a consistent chain of dependencies, it’s better to do it at install time when installing anything new, and running things (to check that no assumption was quietly falsified unbeknownst to you).