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
   

   View Slide

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

   View Slide

3. Organizational Security
   

   View Slide

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

   View Slide

5. Trust
   

   View Slide

6. Know who you trust
   

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

10. Disaster Preparation
    

    View Slide

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
    

    View Slide

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

    View Slide

13. Vendor Code
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. Your Code
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. Assumption: I’m a moron
    

    View Slide

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

    View Slide