Staying Secure on Rails

A (necessarily) incomplete list of things you should consider when it comes to security on Rails.

Transcript

1. Staying Secure on Rails Bradley Grzesiak, partner at Bendyworks (twitter|github).com/listrophy
2. Staying Secure on Rails • Organizational • Vendor Code • Your Code
3. Organizational Security
4. Organizational Security • Trust no one • Trust nothing • You’ve already been hacked • You will continue to be hacked
5. Trust
6. Know who you trust
7. 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
8. It’s not just trust in “Good Intentions...”
9. It’s not just trust in “Good Intentions...” It’s also trust in “Competence.”
10. Disaster Preparation
11. 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
12. Staying Secure on Rails • Organizational • Vendor Code • Your Code
13. Vendor Code
14. Vendor Code • Operating System • User-Level Server Software • Ruby (patch levels) • Gems • Plugins, Submodules, etc
15. Keep Current • ruby-lang.org/en/security • groups.google.com/group/rubyonrails-security • Gemnasium • Twitter
16. Staying Secure on Rails • Organizational • Vendor Code • Your Code
17. Your Code
18. 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
19. 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
20. Assumption: I’m a moron
21. Thank You! speakerdeck.com/listrophy/staying-secure-on-rails