(A cheesy homepage for Justin Collins)
Manually Vendoring Rails 1.2.3 (on Site5)

A few days ago, my shared hosting provider ( Site5 – I do recommend them ) moved my account to a new server. Understandably, this new server had new versions of Ruby and Ruby on Rails. Sadly, my site uses Ozimodo, a (ancient) tumblelog application built for Rails 1.2.3, and I had been unknowingly depending on the global version of Rails. Naturally, my site went kerplumpf once it was moved to the new server.

After fighting with it for some time, I foolishly thought that I was able to just switch directly to Rails 2.3.8. This actually seemed to work for a moment (the main page displayed!) but everything else was still broken.

I attempted to vendor Rails (that is, have a copy of the right version of Rails inside my rails app in vendor/rails) but I kept getting errors like this:

$ rake rails:freeze:gems
(in /home/fair/pkgs/ozimodo)
rake aborted!
undefined method `manage_gems' for Gem:Module

After fussing about for a long while, trying to use different versions of RubyGems and all sorts of silly ideas, I went ahead and found the rails:freeze:gems task (it’s in framework.rake) and manually completed what it is supposed to do automatically:

  1. Install Rails 1.2.3 if you have not already
  2. Create vendor/rails
  3. gem unpack actionmailer (1.3.3), actionpack (1.13.3), actionwebservice (1.2.3), activerecord (1.15.3), activesupport (1.4.2), and rails (1.2.3) into `vendor/rails`
  4. Rename each directory without the version name (e.g., “actionmailer-1.3.3” -> “actionmailer”) except rails.
  5. Rename rails-1.2.3 to railties

You may also need to set GEM_PATH to /home/yourname/ruby/gems, I can’t remember if that was necessary or not.

This was the process, as well as I can remember, which got this site back up and running again.


Pushing Brakeman

I have been trying to do a bit more advertising of Brakeman lately. I have two reasons for doing so: firstly, I think it’s a really useful tool and will make the world a safer place. Secondly, I keep hoping someone else will find bugs in it for me.

One of my design decisions for Brakeman is that it should never crash and should always output some kind of report. I don’t always meet this goal, so I am very interested in any cases where a Rails app will actually make Brakeman fall on its face.

Lately, I have (finally) been putting together a test suite. I’m already finding issues with features I thought were working. Hopefully it will help me avoid embarrassing regressions in the future, too.

If you are in the Los Angeles area, I will be presenting on using Brakeman with Jenkins at the LA OWASP on Wednesday the 25th. Then, next month, I have a similar but unconfirmed talk at LA Ruby. The difference between the two is that I will talk more about Ruby and Rails at the OWASP meeting. At least, I think I will. This blog post is part of my avoiding actually making the slides.

Oh, what is Brakeman? It is a static analysis tool for finding security vulnerabilities in Ruby on Rails applications. It does a pretty good job, most of the time.


Brakeman Updates

Brakeman is a static analysis tool for Ruby on Rails that looks for security vulnerabilities. The cool thing about Brakeman is that pretty much all you need is your code: there is no need to set up a database or a web server or anything of that sort. The code doesn’t even need to be working completely.

Brakeman has been working pretty well for Rails 2.x code, but no one really cares about that any more. Rails 3.x is the new hotness. So I have been working on getting Brakeman to work with Rails 3. The latest gems will attempt to detect Rails 3 automatically (otherwise, there is the `-3` options). There are some known issues to be fixed, but I think it’s past the “catastrophic crash and burn” stage. I would encourage people to try it out.

Also, I have released a Jenkins/Hudson plugin for Brakeman With a minimal amount of setup, you can have Jenkins run Brakeman automatically. It uses another nice plugin to make pretty graphs and tracks the vulnerabilities found so you can see right away when things go wrong.


Brakeman: A Vulnerability Scanner for Ruby on Rails

I spent this summer doing an internship at ATTi, during which I developed a static analysis tool called brakeman for finding security vulnerabilities in Ruby on Rails applications.

What it is

Brakeman uses Ryan Davis’ Ruby Parser to parse the code of your RoR application, mangles it a bit, extracts some information, and then runs various checks on the result. It then uses Ruport to generate a report.

The HTML reports look like this.

Because brakeman analyzes the source code, there is no need to wait until the application is deployed to start testing it. Brakeman can be run at any point in the development process.

What it can do

Right now, brakeman can find these kinds of problems:

  • Cross site scripting vulnerabilities
  • SQL injection
  • Command injection
  • Unsafe redirects
  • Unrestricted mass assignments
  • Insufficient validation regexes
  • Default routes
  • Dynamic render paths

It can also check configuration settings, such as cross site request forgery protection and session secret length.

Unfortunately, it is not (yet?) compatible with Rails 3.0. Hopefully it will still be of use to a lot of people, though.

Installation

Brakeman can be installed as a gem (and, in fact, that is how I would recommend doing it):

gem install brakeman

(may require sudo).

Documentation

brakeman -h provides information on the options available. I’ve also been working on fleshing out the wiki with more detailed info.

Problems?

I really want this to be a useful tool, so if it does not work for you or there are any problems, please file an issue or even just leave a comment on this post. I’ll do my best to get everything fixed up.