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

Securing Your Rails App

99e2a6afab542ba98a9f1d1cae6c9670?s=47 PromptWorks
October 12, 2013

Securing Your Rails App

Watch it online: http://confreaks.com/videos/2733-wickedgoodruby-securing-your-rails-app

How can you know if your Rails app is safe? With potential vulnerabilities lurking in your app’s code, in gems you depend on, in services you use, and in the Rails source itself, attackers have myriad vectors to gain access to your data, interrupt your service, and damage your reputation.

I’ll cover the basics of securing your Rails app, evaluating and mitigating the risk inherent in live web applications, and strategies for keeping your app secure as new threats emerge.

Presented by Mike Nicholaides at Wicked Good Ruby Conf. https://www.promptworks.com

99e2a6afab542ba98a9f1d1cae6c9670?s=128

PromptWorks

October 12, 2013
Tweet

Transcript

  1. Securing Your Rails App Mike Nicholaides @nicholaides promptworks.com

  2. http://promptworks.com! @promptworks

  3. http://xkcd.com/327/

  4. Security

  5. Security is hard

  6. Seriously. It’s really hard.

  7. Are we secure?

  8. Awareness

  9. Know your risks • data • system • network •

    identity
  10. Know your environment •server •network •hardware

  11. Know your perimeter •ops architecture •libraries & services

  12. Security Strategy

  13. Minimize risks Security Strategy

  14. Visibility Security Strategy

  15. Audit Logs •key transactions •blocked access attempts •append-only logs

  16. Alerting •business anomalies •usage anomalies

  17. Have a plan Security Strategy

  18. None
  19. Security as part of the process Security Strategy

  20. That’s great, but what about my Rails app?

  21. Users can submit arbitrary input Fundamental Security Problem:

  22. POST /users HTTP/1.1 Host: innocent-corporation.com Content-Type: application/json Content-Length: 26 !

    { "user": { "name": "Joe Hacker", "admin": true } }
  23. Don’t trust user input

  24. • params • cookies • request headers • url path

    • incoming emails • uploaded files • input from other services • scraped from the web Don’t trust user input
  25. Blacklisting

  26. Blacklisting: Good class Account < ActiveRecord::Base validates :subdomain, exclusion: {

    in: ['www', 'mail'] } end
  27. Blacklisting: Good “WWW” “ www” “” “wwww”

  28. Blacklisting: Bad blacklist = /SELECT|INSERT|UPDATE|DELETE/ ! name = params[:name].gsub(blacklist, '')

    ! Account.where("name = #{name}")
  29. Blacklisting: Bad select selSELECTect SELECT/**/id FROM ... TRUNCATE, DROP, ALTER

  30. Blacklisting •occasionally effective •must know ALL bad inputs

  31. Whitelisting

  32. Whitelisting class User property :admin, Boolean property :name, String property

    :address, String ! attr_accessible :name, :address end
  33. Whitelisting •most effective •least flexible

  34. Sanitization <%= sanitize(@user.bio) %> <h1>About Me</h1> <p>I'm a resourceful developer</p>

    <h1>About Me</h1> <script>performXSS();</script> <p>I'm a resourceful developer</p>
  35. DON’T ROLL YOUR OWN

  36. 1756

  37. Sanitization •effective, but hard •don’t roll your own

  38. Safe Data Handling becomes <script> performXSS(); </script> &lt;script&gt; performXSS(); &lt;/script&gt;

  39. Safe Data Handling becomes 'N Sync WHERE band = '\'N

    Sync'
  40. Safe Data Handling /songs?band=Mary%20Kate%20%26%20Ashley becomes Mary Kate & Ashley

  41. Safe Data Handling • super effective • don’t roll your

    own (if you can help it)
  42. Semantic Checks if current_user.owns? account if account.balance > 0

  43. Handling User Input • Blacklist • Whitelist • Sanitization •

    Safe data handling • Semantic checks
  44. Recommendations

  45. Learn

  46. Rails Security Guide

  47. Code Review

  48. Code Review • Trace user-controllable data • Signatures of common

    vulnerabilities • review risky code
  49. Brakeman

  50. Lean on the community

  51. The Ruby Toolbox

  52. Don’t roll your own •sanitization •escaping/encoding •authentication •cryptography

  53. Devise

  54. None
  55. http://www.schneierfacts.com

  56. http://www.schneierfacts.com

  57. Use Rails

  58. None
  59. Keep Rails up-to-date

  60. Ruby on Rails: Security

  61. Keep gems up-to-date

  62. bundle outdated Outdated gems included in the bundle: * awesome_print

    (1.2.0 > 1.1.0) * axiom-types (0.0.5 > 0.0.4) * builder (3.2.2 > 3.1.4) * cliver (0.3.1 > 0.2.2) * coderay (1.1.0 > 1.0.9) * database_cleaner (1.2.0 > 1.0.1) * descendants_tracker (0.0.3 > 0.0.1) * guard (2.0.3 > 1.8.3) * guard-rubocop (1.0.0 > 0.2.2) * haml_coffee_assets (1.14.1 > 1.14.0) ...
  63. bundler-audit Name: actionpack Version: 3.2.10 Advisory: OSVDB-91452 Criticality: Medium URL:

    http://www.osvdb.org/show/osvdb/91452 Title: XSS vulnerability in sanitize_css in Action Pack Solution: upgrade to ~> 2.3.18, ~> 3.1.12, >= 3.2.13 ! Name: actionpack Version: 3.2.10 Advisory: OSVDB-91454 Criticality: Medium URL: http://osvdb.org/show/osvdb/91454 Title: XSS Vulnerability in the `sanitize` helper of Ruby on Rails Solution: upgrade to ~> 2.3.18, ~> 3.1.12, >= 3.2.13
  64. Keep your code clean

  65. None
  66. http://agileinaflash.blogspot.com/

  67. Regression tests for vulnerabilities

  68. Outside security audit

  69. Security is hard

  70. http://xkcd.com/538/

  71. @nicholaides mike@promptworks.com