Securing Rails


Published on

A talk from 2006 about securing Rails applications. Some information is outdated, but the core concepts should still be useful.

Published in: Technology, Economy & Finance
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Securing Rails

  1. 1. Securing Rails A Whole-Stack Approach RailsConf Europe 2006 Alex Payne
  2. 2. Why Listen To Me? ‣ Half web app developer: • work for political campaigns, non-profits, government, commercial... • presently working for a start-up (who isn’t?) ‣ Half information security geek • offensive and defensive roles • ToorCon, DefCon CTF, etc.
  3. 3. Why Talk About Rails Security? “Security is not likely to ever be a bullet point on the feature list of a framework.” DHH, 2004
  4. 4. Talks Without Code Suck ‣ This is one of those talks. ‣ Sorry. ‣ There’s no magic code-bullet for security (acts_as_impenetrable?)
  5. 5. Key Concepts ‣ Trust. ‣ Security by convention. ‣ Mitigation, not prevention. ‣ You’re as vulnerable as you are valuable. ‣ The holistic approach.
  6. 6. The Whole Stack your Rails app web server database operating system hardware network physical facilities
  7. 7. your Rails app The Usual Suspects ‣ SQL Injection exploiting your trust in user input ‣ Cross-Site Scripting (XSS) exploiting the user’s trust in your content ‣ Cross-Site Request Forgery (XSRF) exploiting your trust in user agent identities
  8. 8. your Rails app SQL Injection SELECT * FROM people WHERE name = ‘bob; DROP DATABASE rails_production; --’; ‣ It’s all about quotes. ‣ Don’t generate SQL based on user- controlled variables. ‣ Honestly, why are we still talking about this?
  9. 9. your Rails app Cross-Site Scripting or: Fifty Ways To Leave Your Server ‣ It’s all about encoding. ‣ <%=h everywhere there’s user input, dangit. ‣ Check the cheat sheet. ‣ Why is sanitizing input in controllers a chore?
  10. 10. your Rails app Cross-Site Request Forgery ‣ It’s all about proving who’s allowed to do what. ‣ OMG, solutions! • security_extensions • secure-action-plugin ‣ If only they ran right on Edge. And were built-in. And gave you a pony for every PUT request.
  11. 11. your Rails app Authentication and ACLs ‣ Here’s where I agree with DHH. ‣ Public by exception is the way to go, IMHO. ‣ Complex ACL systems make me nervous. ‣ My favorite way to hide an admin section: SSH loopback.
  12. 12. your Rails app New Frontiers: AJAX and Web Services Security ‣ Do you trust code from other domains? Can you afford not to? ‣ What if Google Maps changed its name to Mallory? ‣ Validate trust on every request; I’ll pay for the extra CPU time.
  13. 13. your Rails app New Frontiers: Distributed Applications ‣ Where are your DRb requests coming from? ‣ Amazon EC2: Hey! You! Get off of my cloud! ‣ Flip the SSL bit. • An aside: don’t make SSL an “extra”
  14. 14. your Rails app New Frontiers: The Way-Out-There Stuff Java kids call it “reflection injection”; I call it “don’t use #constantize with user input”
  15. 15. web server Running Mongrel Yet? ‣ Jeepers, it’s the fuzz! ‣ Who’s audited your HTTP load balancer-’o-the-month? ‣ There’s something to be said for Apache...
  16. 16. web server Side Channels or: Mo’ Features, Mo’ Problems ‣ A little thing called “attack surface.” ‣ Ixnay on the ebDAVWay (uh, WebDAV). ‣ Your app-layer security doesn’t matter if you’re vulnerable lower down the stack.
  17. 17. database Isolation (or: 100GB of Solitude) ‣ Databases are about open access. ‣ Don’t give attackers the chance: use firewalls, physical network isolation, and ACLs. ‣ Especially if you’re running a cluster.
  18. 18. Interlude: What Are They Using at the web app/HTTP/DB layer ‣ Nikto ‣ WebScarab ‣ Firefox - with the right extensions
  19. 19. Interlude: Owning Ruby or: Sure, It’s Funny When It Happens To PHP... ‣ It’s still written in C, kids. ‣ So are the libraries it wraps.
  20. 20. operating system Mythbusters ‣ OS security is the result of process, not philosophy... ‣ ... and that doesn’t just mean open source vs. closed source. ‣ Running OpenBSD won’t solve all your problems.
  21. 21. operating system Make Reasonable Choices ‣ Choose your OS for performance and maintainability, not security. ‣ Keeping up to date is the best defense: • auto-sync your ports tree (or equivalent) • be the first to know: subscribe to your OS vendor’s vulnerability RSS feed
  22. 22. hardware Does Your Choice Of Gear Effect Your Security Posture? ‣ Nobody writes exploits for SPARC, so that’s something... ‣ Blue Pill: what if your chipset was host to the nastiest rootkit e-var? • Unless you’re running your production app on Vista, I wouldn’t sweat it (for the next six months).
  23. 23. network Firewalls or: Filtered Packets Are My Favorite Packets • Learn, live, and love pf. • It’s nice that your hosting provider has a firewall. Get your own. • You never know when an OS update might turn on (or off) a vulnerable service.
  24. 24. network SSH ‣ Run it on a high port. ‣ Use key-based authentication. ‣ You’ve seen these recommendations umpteen times because they’re good ones.
  25. 25. network IDS, IPS, NIDS, HIDS, and BS • Captain! They’re breaching the hull! • Do you have time to follow up on every halfway- scary security event? Didn’t think so. • If security monitoring really a concern, outsource it. • Learn from the experts.
  26. 26. physical facilities Access Control ‣ Biometric? ‣ Keys, cards, tokens? ‣ Handling money? Demand multi-factor!
  27. 27. Add Carefully To Your Stack ‣ Research everything: software, hardware, and facilities. ‣ Keep it simple (just like in every other problem domain). ‣ Secunia is your friend.
  28. 28. Side Channels ‣ Google hacking it’s a thing, and it works ‣ owning your repository where’s your code at? ‣ owning your development code ...and the machine it’s on!
  29. 29. More Stuff They’re Using ‣ BiDiBLAH - it does everything ‣ Qualys - for the suits ‣ Metasploit - oh noes! the bad guys have their own Ruby framework! ‣ CORE IMPACT - all caps means it works that much better.
  30. 30. Recommendations ‣ Security by convention, not configuration (it’s supposed to be the Rails way!) ‣ Build security into your testing cycle. ‣ Make realistic security decisions. ‣ Rails (and Ruby!) security feeds to complement the new mailing list.
  31. 31. Resources ‣ Open Source Web Application Security Project ‣ Web Hacking Incidents Database ‣ Not the Rails wiki so much... let’s change that!
  32. 32. Fin. You can grab a PDF of this talk at Questions?