$30 off During Our Annual Pro Sale. View Details »

Staying Secure on Rails

listrophy
February 25, 2013

Staying Secure on Rails

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

listrophy

February 25, 2013
Tweet

More Decks by listrophy

Other Decks in Programming

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