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

Software Mischief (Part 1)

Software Mischief (Part 1)

I gave this presentation at an internal Oracle tech talk to serve as a primer on a few common security vulnerabilities in Rails applications. The mentioned bug was in a new feature buried behind a beta flag and didn't actually affect any customers, but it's always good to refresh everyone on things like this that can easily slip into large projects unnoticed.

Elliott Wood

April 26, 2013
Tweet

More Decks by Elliott Wood

Other Decks in Programming

Transcript

  1. SOFTWARE ischief

  2. a short DEMO

  3. OUR PLATFORM a short DEMO on * well, i’m demoing

    on staging so i don’t screw with customer data, but this definitely exists on production
  4. OUR PLATFORM PRODUCTION a short DEMO on * well, i’m

    demoing on staging so i don’t screw with customer data, but this definitely exists on production *
  5. OUR PLATFORM PRODUCTION a short DEMO on YES,THIS IS FOR

    REAL * well, i’m demoing on staging so i don’t screw with customer data, but this definitely exists on production *
  6. None
  7. HACKER think LIKE A INJECTION block URL FORGERY CROSS-SITE REQUEST

    prevent
  8. HACKER think LIKE A

  9. HACKER think LIKE A assume all users are malicious

  10. HACKER think LIKE A assume all users are malicious this

    is the INTERNET after all.
  11. HACKER think LIKE A assume all users are malicious this

    is the INTERNET after all. people on the internet are not nice.
  12. HACKER think LIKE A know their methods

  13. HACKER think LIKE A know their attack vectors

  14. HACKER think LIKE A design security in layers

  15. HACKER think LIKE A design security in layers this could

    have been just an injection bug. one customer would have to attack another customer.
  16. HACKER think LIKE A design security in layers this could

    have been just an injection bug. one customer would have to attack another customer. or, this could have been just a CSRF bug. an attacker would have to target a user’s specific ad.
  17. HACKER think LIKE A design security in layers this could

    have been just an injection bug. one customer would have to attack another customer. or, this could have been just a CSRF bug. an attacker would have to target a user’s specific ad. the combination lets third parties attack our customers.
  18. HACKER think LIKE A design security in layers this could

    have been just an injection bug. one customer would have to attack another customer. or, this could have been just a CSRF bug. an attacker would have to target a user’s specific ad. the combination lets third parties attack our customers. that’s significantly worse.
  19. INJECTION URL

  20. server sends a form to the client INJECTION URL client

    submits form back to server
  21. server sends a form to the client INJECTION URL client

    submits form back to server client edits the HTML source
  22. server sends a form to the client INJECTION URL client

    submits form back to server client edits the HTML source
  23. what if the :id is an external post id? are

    you verifying that it exists on the resource that you authorized? what if the :id is passed to a gem? an api? are you assuming that the api or gem is handling authorization for you? is it? INJECTION URL
  24. INJECTION URL meanwhile, inside a Rails Engine...

  25. FORGERY CROSS-SITE REQUEST

  26. STEP 1: log in to a website FORGERY CROSS-SITE REQUEST

  27. STEP 1: log in to a website STEP 2: visit

    a malicious site FORGERY CROSS-SITE REQUEST
  28. FORGERY CROSS-SITE REQUEST what if that form submits hidden fields

    to a different server? is your SRMA session cookie still valid?
  29. FORGERY CROSS-SITE REQUEST GOOD NEWSRails protects you from this automatically!

    ERROR: Can't verify CSRF token authenticity
  30. FORGERY CROSS-SITE REQUEST 1. A secret form_autheticity_token is added to

    all forms in your application. 2. That token matches a key in your application session cookie. 3. If a form submission comes in without a valid token, it is rejected.
  31. FORGERY CROSS-SITE REQUEST GOOD NEWSRails protects you from this automatically!

    BAD NEWS You can shoot. yourself in the foot.
  32. FORGERY CROSS-SITE REQUEST

  33. FORGERY CROSS-SITE REQUEST GET requests are not protected! Don’t use

    GET requests for actions that modify data. Don’t use match to define routes, because it accepts both POST and GET requests.
  34. FORGERY CROSS-SITE REQUEST GET requests are not protected! Don’t use

    GET requests for actions that modify data. Don’t use match to define routes, because it accepts both POST and GET requests.
  35. FORGERY CROSS-SITE REQUEST GET requests are not protected! Don’t use

    GET requests for actions that modify data. Don’t use match to define routes, because it accepts both POST and GET requests.
  36. FORGERY CROSS-SITE REQUEST the cause...

  37. None
  38. HACKER think LIKE A INJECTION block URL FORGERY CROSS-SITE REQUEST

    prevent
  39. SOFTWARE ischief Q + A