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.

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 *
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...
38. HACKER think LIKE A INJECTION block URL FORGERY CROSS-SITE REQUEST prevent
39. SOFTWARE ischief Q + A