Securing Rails

32
Securing Rails A Whole-Stack Approach RailsConf Europe 2006 Alex Payne www.al3x.net

description

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

Transcript of Securing Rails

Page 1: Securing Rails

Securing RailsA Whole-Stack Approach

RailsConf Europe 2006

Alex Paynewww.al3x.net

Page 2: Securing Rails

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.

Page 4: Securing Rails

Talks Without Code Suck

‣ This is one of those talks.

‣ Sorry.

‣ There’s no magic code-bullet for security (acts_as_impenetrable?)

Page 5: Securing Rails

Key Concepts

‣ Trust.

‣ Security by convention.

‣ Mitigation, not prevention.

‣ You’re as vulnerable as you are valuable.

‣ The holistic approach.

Page 6: Securing Rails

The Whole Stackyour Rails app

web server database

operating system

hardware

network

physical facilities

Page 7: Securing Rails

‣ 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

Page 8: Securing Rails

‣ 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; --’;

Page 9: Securing Rails

‣ 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

Page 10: Securing Rails

‣ 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

Page 11: Securing Rails

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.

Page 12: Securing Rails

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.

Page 13: Securing Rails

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”

Page 14: Securing Rails

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”

Page 15: Securing Rails

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

Page 16: Securing Rails

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

Page 17: Securing Rails

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.

Page 19: Securing Rails

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.

Page 20: Securing Rails

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.

Page 21: Securing Rails

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

Page 22: Securing Rails

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

Page 23: Securing Rails

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

Page 24: Securing Rails

SSH

‣ Run it on a high port.

‣ Use key-based authentication.

‣ You’ve seen these recommendations umpteen times because they’re good ones.

network

Page 25: Securing Rails

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

Page 26: Securing Rails

Access Control

‣ Biometric?

‣ Keys, cards, tokens?

‣ Handling money? Demand multi-factor!

physical facilities

Page 27: Securing Rails

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.

Page 28: Securing Rails

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!

Page 29: Securing Rails

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.

Page 30: Securing Rails

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.

Page 31: Securing Rails

Resources

‣ Open Source Web Application Security Project

‣ Web Hacking Incidents Database

‣ Not the Rails wiki so much... let’s change that!

Page 32: Securing Rails

Fin.

You can grab a PDF of this talk at

http://al3x.net/securing_rails.pdf

Questions?