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

OWASP Chicago - Ruby on Rails Pitfalls

OWASP Chicago - Ruby on Rails Pitfalls

In this talk, Matt Konda and I talk about common security issues with Rails apps and encourage our security audience to find ways to meet with and work with the Ruby/Rails community.

Jonathan Claudius

January 10, 2013
Tweet

More Decks by Jonathan Claudius

Other Decks in Technology

Transcript

  1. Agenda ž  Background ž  Pitfall Examples —  XSS —  Mass

    Assignment —  SQLi —  /dev/random ž  Tools to Help
  2. Why are we doing this? ž  Rails is a popular

    and interesting platform in much need of security attention. ž  At a recent ChicagoRuby Meetup, 2 of 97 attendees had ever heard of OWASP. We want to change that. We want you to help.
  3. Rails Background ž  Favors convention over configuration ž  Leverages dynamic

    Ruby language features ž  Makes development process fast and simple ž  Default restful interface and xml + json API's ž  Very healthy library ecosystem ž  Popular with developers for prototyping and rapid small team application development ž  Also used for large scale applications
  4. Rails Background The same thing that makes it easy to

    use and powerful, makes it a rich target.
  5. XSS ž  Rails 2.x need to escape text. ž  Rails

    3.x should escape everything. ž  Rails 2.x need to escape text. ž  Rails 3.x should escape everything. ž  However, in the case where a programmer wants to store unescaped input this can be bypassed. Happens all the time.
  6. XSS – Example CKEditor ž  CKEditor setup: —  Application.js — 

    Form page —  Controller: No change. Show view however:
  7. Solution ž  Remove rich text … ž  Use sanitization ž 

    Still need to be sort of heavy handed, probably would need to disallow <img/>. http://apidock.com/rails/ActionView/Helpers/SanitizeHelper/sanitize
  8. Mass Assignment ž  A feature in Rails that allows record

    creation from values in a hash. ž  Made famous by Egor Homahov —  Demonstrated rails vulnerability by exploiting GitHub, which runs on rails, to make a commit to the rails source code.
  9. Mass Assignment Example ž  Normal Example ž  Exploit Example Reference:

    http://railscasts.com/episodes/26-hackers-love-mass-assignment
  10. SQL Injection ž  Recently been a topic of interest for

    the Rails community —  CVE-2012-2661 (6 months ago) —  CVE-2012-5664 (< 2 weeks ago) ž  Both are deficiencies in framework provided protections.
  11. CVE-2012-2661 (May 31, 2012) ž  Code like this: ž  Can

    be manipulated to make params[:id] look like a hash. ž  Solution: Update to Rails: 3.2.4, 3.1.5, 3.0.13 or cast: http://seclists.org/oss-sec/2012/q2/448
  12. CVE-2012-5664 (Jan 2, 2013) ž  Code like this: ž  Can

    be manipulated to process input as options to query. ž  Solution: Update to Rails 3.2.10, 3.1.9, 3.0.18 or cast: https://groups.google.com/forum/#!topic/rubyonrails-security/DCNTNp_qjFM
  13. CVE-2013-0155 (Jan 8, 2013) ž  Code like this: —  find_by_*

    —  Model.where(:name => params[:name]) ž  Can be made to bypass a query where clause by sending an empty hash in params[:name] ž  Variant of CVE-2012-2660 CVE-2012-2694 ž  Solution: Update to Rails: 3.2.11, 3.1.10, 3.0.19 or cast to string. https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI
  14. CVE-2013-0156 (Jan 8, 2013) ž  Any code that accepts XML

    params. (All) ž  Create symbols. Parse YAML. Basically remote code execution. Not SQLi but exascerbates other SQLi vulns due to symbol manipulation. ž  Solution: Update to Rails 3.2.11, 3.1.10, 3.0.19, 2.3.15, disable XML / YAML interfaces or disable capabilities within XML parsing. https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ https://gist.github.com/4499206 - postmodern RCE
  15. Time out for tenderlovemaking ž  Aaron Patterson might have had

    a bad week. We don't wish that on anyone. ž  He in turn wants to thank these folks: “Ben Murphy, Magnus Holm, Felix Wilhelm, Darcy Laycock, Jonathan Rudenberg, Bryan Helmkamp, Benoist Claassen and Charlie Somerville for reporting the issue to us and working with us to ensure the fixes worked.”
  16. Session Management ž  By default, Rails uses a cookie based

    session. —  People put all kinds of things in the session. —  They never expire. Easy to replay after logout. ž  Open source apps sometimes use public secret for signing cookies. ž  Recommendations —  Use the database based session and expire them. —  Update your secret and keep it secret.
  17. CSRF ž  Need to ensure that controllers protect from forgery:

    ž  Can sometimes find this disabled for API methods – as for show method below.
  18. Grab Bag ž  Forceful Browsing ž  Writing an API ž 

    Password Complexity ž  Filter Logs ž  Secure Cookies ž  File Upload ž  3rd Party Dependencies ž  Routes ž  Sensitive Files
  19. Rails Casts ž  Some Episodes on Rails Security —  #20

    – Restricting Access —  #25 – SQL Injection —  #27 – Cross-site Scripting —  #26 – Hackers Love Mass Assignment —  #178 – Security Tips —  #204 – XSS Protection in Rails 3 —  #352 – Securing an API —  #356 – Dangers of Session Hijacking http://railscasts.com/
  20. Brakeman ž  A static analysis security vulnerability scanner for Ruby

    on Rails applications. —  https://github.com/presidentbeef/brakeman ž  Demo —  Identify vulnerabilities in Rails Apps
  21. ChicagoRuby ž  Chicago has an awesome Ruby community. ž  12/4/2012

    we presented to ChicagoRuby on Rails Security. We were fortunate to receive a favorable response and lots of interesting follow up conversations. ž  2/13/2013 we have been invited back to do a Ruby “Hack Night” where we'll have folks run brakeman and fix security problems. We would LOVE to have you come help us!