Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,132
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
39
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Securing Rails A Whole-Stack Approach RailsConf Europe 2006 Alex Payne www.al3x.net
  • 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. 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. Talks Without Code Suck ‣ This is one of those talks. ‣ Sorry. ‣ There’s no magic code-bullet for security (acts_as_impenetrable?)
  • 5. Key Concepts ‣ Trust. ‣ Security by convention. ‣ Mitigation, not prevention. ‣ You’re as vulnerable as you are valuable. ‣ The holistic approach.
  • 6. The Whole Stack your Rails app web server database operating system hardware network physical facilities
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Interlude: What Are They Using at the web app/HTTP/DB layer ‣ Nikto ‣ WebScarab ‣ Firefox - with the right extensions
  • 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. 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. 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. 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. 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. 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. 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. physical facilities Access Control ‣ Biometric? ‣ Keys, cards, tokens? ‣ Handling money? Demand multi-factor!
  • 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. 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. 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. 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. Resources ‣ Open Source Web Application Security Project ‣ Web Hacking Incidents Database ‣ Not the Rails wiki so much... let’s change that!
  • 32. Fin. You can grab a PDF of this talk at http://al3x.net/securing_rails.pdf Questions?