Securing Rails
Upcoming SlideShare
Loading in...5
×
 

Securing Rails

on

  • 5,463 views

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.

Statistics

Views

Total Views
5,463
Views on SlideShare
5,436
Embed Views
27

Actions

Likes
2
Downloads
39
Comments
0

4 Embeds 27

http://coderwall.com 13
http://www.slideshare.net 9
https://www.linkedin.com 3
http://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Securing Rails Securing Rails Presentation Transcript

  • Securing Rails A Whole-Stack Approach RailsConf Europe 2006 Alex Payne www.al3x.net
  • 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.
  • Why Talk About Rails Security? “Security is not likely to ever be a bullet point on the feature list of a framework.” DHH, 2004
  • Talks Without Code Suck ‣ This is one of those talks. ‣ Sorry. ‣ There’s no magic code-bullet for security (acts_as_impenetrable?)
  • Key Concepts ‣ Trust. ‣ Security by convention. ‣ Mitigation, not prevention. ‣ You’re as vulnerable as you are valuable. ‣ The holistic approach.
  • The Whole Stack your Rails app web server database operating system hardware network physical facilities
  • 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
  • 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?
  • 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?
  • 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.
  • 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.
  • 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.
  • 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”
  • 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”
  • 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...
  • 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.
  • 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.
  • Interlude: What Are They Using at the web app/HTTP/DB layer ‣ Nikto ‣ WebScarab ‣ Firefox - with the right extensions
  • 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.
  • 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.
  • 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
  • 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).
  • 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.
  • network SSH ‣ Run it on a high port. ‣ Use key-based authentication. ‣ You’ve seen these recommendations umpteen times because they’re good ones.
  • 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.
  • physical facilities Access Control ‣ Biometric? ‣ Keys, cards, tokens? ‣ Handling money? Demand multi-factor!
  • 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.
  • 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!
  • 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.
  • 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.
  • Resources ‣ Open Source Web Application Security Project ‣ Web Hacking Incidents Database ‣ Not the Rails wiki so much... let’s change that!
  • Fin. You can grab a PDF of this talk at http://al3x.net/securing_rails.pdf Questions?