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

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?