Securing RailsA Whole-Stack Approach
RailsConf Europe 2006
Alex Paynewww.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?
DHH, 2004
“Security is not likely to ever be a bullet point on the feature list of a framework.”
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 Stackyour Rails app
web server database
operating system
hardware
network
physical facilities
‣ SQL Injectionexploiting 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
The Usual Suspects
your Rails app
‣ It’s all about quotes.
‣ Don’t generate SQL based on user-controlled variables.
‣ Honestly, why are we still talking about this?
SQL Injection
your Rails app
SELECT * FROM people WHERE name = ‘bob; DROP DATABASE rails_production; --’;
‣ It’s all about encoding.
‣ <%=h everywhere there’s user input, dangit.
‣ Check the cheat sheet.
‣ Why is sanitizing input in controllers a chore?
Cross-Site Scriptingor: Fifty Ways To Leave Your Server
your Rails app
‣ 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.
Cross-Site Request Forgery
your Rails app
Authentication and ACLs
your Rails app
‣ 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.
New Frontiers:AJAX and Web Services Security
your Rails app
‣ 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.
New Frontiers:Distributed Applications
your Rails app
‣ 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”
New Frontiers:The Way-Out-There Stuff
your Rails app
Java kids call it “reflection injection”;
I call it “don’t use #constantize with user input”
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 Channelsor: 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.
web server
Isolation(or: 100GB of Solitude)
database
‣ 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 Usingat the web app/HTTP/DB layer
‣ Nikto
‣WebScarab
‣ Firefox - with the right extensions
Interlude:
Owning Rubyor: 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
‣ 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
Make Reasonable Choices
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).
hardware
Firewallsor: 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.
network
Access Control
‣ Biometric?
‣ Keys, cards, tokens?
‣ Handling money? Demand multi-factor!
physical facilities
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?