Austin on Rails – July 28, 2015

I’m saving some notes from the second talk of this Austin on Rails meeting so I don’t lose them somewhere on my phone.

Securing Rails for the Enterprise – Marcus J. Carey

Marcus was that rare speaker: very casual, very entertaining, and very informative.

Here are some of the tools he mentioned.

General Purpose Tools

  1. PaperTrail – A tool to manage your logs. He recommends only logging errors so it’s really obvious when something is happening.
  2. Burp – General purpose security, most basic tool, number 1 most used tool by people who will try to break in.
  3. Zap – General purpose security tool.
  4. Nikto – General purpose security tool.

Rails-specific

  1. Breakman – Rails-specific security scanner
  2. Bundler audit – checks your gems and gem dependancies for vulnerabilities
  3. Gem Canary – Similar to bundler audit.
  4. Devise – secure authentication!
  5. Devise-zxcvbn – rejects weak user passwords
  6. devise-security-extension – enterprise-level security for devise
  7. devise-google-authenticator – add 2-factor auth to your app that works with Google’s Authenticator app.
General Rails advice:
  • User models should never inherit from active-record::base
  • Use uuid’s instead of sequential ids/keys
  • Rely on current_user from devise instead of anything else
  • No capitals in the controller!
  • When a test is especially short or simple compared to the application code it tests, lean toward writing the test first.
  • When the desired behavior isn’t yet crystal clear, lean toward writing the application code first, then write a test to codify the result.
  • Because security is a top priority, err on the side of writing tests of the security model first.
  • Whenever a bug is found, write a test to reproduce it and protect against regressions, then write the application code to fix it.
  • Lean against writing tests for code (such as detailed HTML structure) likely to change in the future.
  • Write tests before refactoring code, focusing on testing error-prone code that’s especially likely to break.

— Michael Hartl, Ruby on Rails Tutorial