Rails Security
2 likes2,268 views
The document emphasizes the critical importance of security in web applications, particularly for Ruby on Rails developers, highlighting the increasing risks as personal data moves online. It outlines realistic security goals and best practices, including mitigating common vulnerabilities like mass assignment, file uploads, and XML parsing. The author urges developers to incorporate good security practices from the beginning and provides various resources for further learning.
![1. A Silly Vulnerability
A newbie
mistake…
…here’s the exploit:
curl –d ‘forum_id=1&message[subject]=foobar’ http://yoursite.com/forums](https://image.slidesharecdn.com/railssecurity-111229144046-phpapp01/85/Rails-Security-7-320.jpg)
Rails Security
- 1. Rails Security : It’s Not Just a Good Idea By David Keener
- 2. Introduction Why security matters Realistic goals Learning good practices …by looking at some bad practices Resources Some final thoughts
- 3. Who Am I? Long-time Ruby/Rails developer Founder/Organizer – RubyNation & DevIgnition conferences Last 3 projects… - Online Video Contest: With $10K-plus prizes… - Bank: Online charitable donations via credit card - Cyber Security: <cannot discuss details> “School of hard knocks” for security
- 4. Why Security Matters More personal data is moving online than ever before Social networks, retail sites, mobile devices, etc. The community of “bad actors” is growing and it’s international The Internet is everywhere If the data in your app has value, someone WILL try to get to it RSA is THE ultimate example There are serious legal ramifications to security breaches
- 5. Realistic Goals Security is a BIG topic Nobody can cover it all in one talk Goal 1: Illustrate how important security is Goal 2: Demonstrate some good practices (and a few bad mistakes) Goal 3: Point you to some awesome resources
- 6. “…out of 300 audited sites, 97% are vulnerable to attack” - From a Gartner Group survey
- 7. 1. A Silly Vulnerability A newbie mistake… …here’s the exploit: curl –d ‘forum_id=1&message[subject]=foobar’ http://yoursite.com/forums
- 8. 1. Mitigation Option 1: Include the before filter in proper controller Option 2: Create a NoAuth controller… - ApplicationController: before_filter :login_required - NoAuthController: skip_before_filter :login_required General Rule: “Default Deny” is your friend. Also: Be aware of code smells such as out-of-control before-filter stacks, filters with non-obvious side effects, etc.
- 9. 2. Mass Assignment How many times have we seen this: Mass assignment is convenient…but it’s not safe.
- 10. 2. Mitigation Mass assignment – only for fields with no security impact ALL models should use attr_accessible to specify fields that can be mass-assigned attr_accessible :first_name, :last_name, :email Other fields can be individually assigned if needed
- 11. 3. Regexes What’s wrong with this code?
- 12. 3. Mitigation The regular expression uses ^ and $ to match the start and end of the string In Ruby, this only matches a single line if multi-line input is provided Use A and z instead for input validation
- 13. 4. File Uploads views/uploads/new.html.erb controllers/uploads.rb Uploads are prone to numerous potential security issues…
- 14. 4. Problems The original file is left in the /tmp directory - Under a name like Rack*multipart*{random stuff} - Executable files could theoretically be executed by someone (BAD) The uploaded file is copied to $RAILS_ROOT/public/data - Under a name like Rack*multipart*{random stuff} - The file is web-accessible - Embedded JavaScript will have server access (BAD) - Could potentially see files uploaded by other users (PRIVACY) Uploaded files are never cleaned up File names can have collisions
- 15. 4. Mitigations File in /tmp directory - Remove the file immediately after it has been copied File is copied to $RAILS_ROOT/public/data - Copy files to a non-web-accessible dir - Validate file types and eliminate undesirable files - Ensure that files are never left as executable Uploaded files never cleaned up - Delete files when no longer needed File names can have collisions - Add a unique ID as a filename prefix to prevent name collisions
- 16. 5. Uploading XML Files What if I want to … upload and parse an XML File? It’s called an XML External Entity Expansion Attack…
- 17. 5. Mitigation Options Option 1: Before parsing, regex for !DOCTYPE, !ELEMENT or !ENTITY and immediately reject the file - No need to be nice to the user Option 2: Disable entity expansions - Differs based on XML parser used
- 18. 5. Mitigation - Nokogiri Parse settings - Validates the XML against the XSD - noent => No entity expansions - nonet => No network access - Does not actually do external entity expansions, but the infrastructure is there
- 19. 5. Mitigation - REXML - Non-validating parser - entity_expansion_limit: raises exception if it finds any entity expansions - Not actually required to do entity expansions, but it seems to have some of the infrastructure
- 20. Some Best Practices Here are a few more best practices Always sanitize user-provided input Rolling your own authentication is an anti-pattern…think twice - Use Devise, restful_authentication, CanCan, etc. Use database-backed session storage “Default Deny” is your friend Use SSL for secure logins in production
- 21. Resources Rails Security Guide http://guides.rubyonrails.org/security.html OWASP Ruby on Rails Security Guide V2 https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Ra ils_Security_Guide_V2 DHS Sensitive Systems Policy Directive 4300A http://www.uscg.mil/hq/cg9/NAIS/RFP/SectionJ/dhs-4300A- policy.pdf
- 22. Conclusion Security matters... Compromising PII or financial info will always be BAD It’s easier to build security in from the beginning than to retrofit it later Make good security practices second nature now…they will pay off later The security of your app must be TESTED RSpec, Cucumber and similar tools are essential
- 23. It’s smooth sailing If you build good security practices into your app…
- 24. Questions Feel free to contact me: dkeener@keenertech.com david.keener@gd-ais.com Twitter: dkeener2010 Blog: http://www.keenertech.com We’re also looking for some good Rubyists…