Ruby on Rails Security 101

A beginners guide

This post is based on a lightning talk I gave at the Melbourne Ruby Group’s Newbie Night on August 29th 2013.

Security is a very broad topic, so a lightning talk can’t even begin to scratch the surface. The three things you need to know are:

1. People fuck it up all the time.
2. You will too.
3. Hopefully you don’t make the news.

You should know where to look in order to protect yourself.

Don’t be fooled into a false sense of security — source

Know Your Tools

Ruby on Rails is a tool, one that you will rely heavily on to make you efficient and keep you secure. Reading the security policy will help you understand the process Rails goes through when security issues are identified and reported.

The most important take away is that you should subscribe yourself and your colleagues to the Ruby on Rails security mailing list.

Then you need to always be in a position where you can upgrade Rails and deploy a new version of your application. Every minute you’re running a version of Rails with a known security vulnerability is a minute closer to you having a really bad time. It won’t take long before metasploit is updated to target that vulnerability.

Know Your Domain

If you’re going to build a web application, you need to understand the types of vulnerabilities that are common. Even if you’re not running banking software, your application will be exposed to these types of exploits: your servers are still useful to a botnet.

The Open Web Application Security Project (OWASP) is a great resource for understanding the general problems. They maintain a list of top 10 exploits:

• Injection
• Broken Authentication and Session Management
• Cross-Site Scripting (XSS)
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery (CSRF)
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards

If you don’t know what these terms mean, you’ve got a lot to learn.

Thankfully OWASP have a Rails Cheat Sheet. Which covers a lot of these vulnerabilities, including code samples. It’s a companion guide to the official Rails Security Guide which you should also read.

The top vulnerability listed by OWASP is injection attacks. One particular type of injection attack is the SQL injection attack. If you’re using Rails as it comes out of the box, then you’re using ActiveRecord to talk to your database. It’s generally a safe library to use, and will sanitize raw SQL arguments for you. Some of ActiveRecord’s API however does not, the Rails SQL Injection site maintains a list of unsafe ActiveRecord API’s. It’s a great lesson in what not to do.

Finally, the Code Climate blog has an excellent article on Rails Insecure Defaults. If you care about your craft, you can do much worse than to read their blog and the articles they link to on twitter.

Build a Safety Net

There is an aweful lot to take in and understand. The good news is that a lot of best practices and misuse of API’s can be found using static code analysis (a program that reads your code).

Brakeman Scanner is one such tool. It’s purpose build to scan Ruby on Rails applications and detect known vulnerabilities. You should add it to your test suite, fail the build if it finds anything.

Can someone do it for you? Yes, yes they can. Code Climate is a hosted service that will analyse your code base for all sorts of bad practices, including known security vulnerabilities. Well worth the money if you value your code base.

Twitter’s Secure Headers gem is also worth a look if you want to be forward thinking and offer extra protection to your users on modern browser. It won’t help those stuck on IE6 though.

Finally, the Rack Protection gem is another line of defense you can add to your code base. It prevents all sorts of interesting attacks before they even hit your Rails code.

In Summary

Security is hard. Understand your tools, your domain, and build a safety net into your application and development life cycle. Don’t trust me though, verify everything yourself.

If in doubt,hire a security expert.