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.
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?