Staying Secure on Rails Bradley Grzesiak, partner at Bendyworks (twitter|github).com/listrophy 

Staying Secure on Rails • Organizational • Vendor Code • Your Code 

Organizational Security 

Organizational Security • Trust no one • Trust nothing • You’ve already been hacked • You will continue to be hacked 

Trust 

Know who you trust 

Who do I trust? • Intel, Samsung, etc & Factory Workers • Apple • GCC & LLVM Teams • Ruby Core Team • Rails Core Team • Authors of Every Gem You Use • GitHub & Rubygems.org • Google or Mozilla • OpenSSH Team • Linus Torvalds & GNU Team • Ubuntu Team • Apache or nginx Team • Heroku, Linode, Engine Yard, Blue Box • Amazon 

It’s not just trust in “Good Intentions...” 

It’s not just trust in “Good Intentions...” It’s also trust in “Competence.” 

Disaster Preparation 

Disaster Preparation • Up-to-date List of Apps & Servers • Effective Code & Data Backups • Insta-Maintenance Pages • Fast Re-Deployment, Provisioning Process • Status Pages • “Phone” Tree 

Staying Secure on Rails • Organizational • Vendor Code • Your Code 

Vendor Code 

Vendor Code • Operating System • User-Level Server Software • Ruby (patch levels) • Gems • Plugins, Submodules, etc 

Keep Current • ruby-lang.org/en/security • groups.google.com/group/rubyonrails-security • Gemnasium • Twitter 

Staying Secure on Rails • Organizational • Vendor Code • Your Code 

Your Code 

Your Code • Never trust params • If you recurse/loop on params, set limits • Don’t call .to_sym on params • Use attr_accessible • Actually, use strong_parameters • Filter Parameters: password, cc info, etc • Bcrypt your passwords • Actually, don’t roll your own auth • Don’t store credit card info • Better yet, never touch credit card info • Judiciously trust DB field values • Never use eval; Judiciously use .raw • Avoid SQL injection • Don’t use cookie session store 

Your Code • Don’t put arbitrary restrictions on passwords, other than maybe length • Authenticating? Force SSL everywhere • Auth or “mark-as-skipped” every action • Know how much information you leak • Don’t rely on obscurity • Use a load balancer • If you use OAuth, learn it • Assume hackers are smarter than you and have your code • Git-ignore secrets (eg: secret_token.rb) • Use JSON if you must serialize • Don’t disable CSRF tokens • Email is insecure • Read guides.rubyonrails.org/security.html 

Assumption: I’m a moron 

Thank You! speakerdeck.com/listrophy/staying-secure-on-rails