Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Staying Secure on Rails

B4753ed732e72ff2568262c9387bbc4c?s=47 listrophy
February 25, 2013

Staying Secure on Rails

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

B4753ed732e72ff2568262c9387bbc4c?s=128

listrophy

February 25, 2013
Tweet

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