0
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, comme...
Why Talk About Rails Security?


            “Security is not
            likely to ever be a
            bullet point on
...
Talks Without Code Suck

  ‣   This is one of those talks.
  ‣   Sorry.
  ‣   There’s no magic code-bullet for
      secur...
Key Concepts

‣   Trust.
‣   Security by convention.
‣   Mitigation, not prevention.
‣   You’re as vulnerable as you are v...
The Whole Stack
       your Rails app

  web server      database

     operating system

         hardware

          net...
your Rails app


           The Usual Suspects

‣   SQL Injection
    exploiting your trust in user input

‣   Cross-Site ...
your Rails app


                 SQL Injection
SELECT *
FROM people
WHERE name = ‘bob; DROP DATABASE rails_production; --...
your Rails app

             Cross-Site Scripting
         or: Fifty Ways To Leave Your Server




‣   It’s all about enco...
your Rails app


        Cross-Site Request Forgery
‣   It’s all about proving who’s allowed to do what.
‣   OMG, solution...
your Rails app


       Authentication and ACLs

‣   Here’s where I agree with DHH.
‣   Public by exception is the way to ...
your Rails app

                New Frontiers:
          AJAX and Web Services Security


‣   Do you trust code from other...
your Rails app

                 New Frontiers:
                Distributed Applications


‣   Where are your DRb requests...
your Rails app

             New Frontiers:
           The Way-Out-There Stuff



Java kids call it “reflection injection”...
web server



Running Mongrel Yet?

‣ Jeepers, it’s the fuzz!
‣ Who’s audited your HTTP load
  balancer-’o-the-month?

‣ T...
web server


        Side Channels
      or: Mo’ Features, Mo’ Problems



‣ A little thing called “attack surface.”
‣ Ixn...
database


                Isolation
              (or: 100GB of Solitude)




‣   Databases are about open access.
‣   Do...
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.
 ...
operating system



            Mythbusters

‣ OS security is the result of process, not
  philosophy...
‣ ... and that do...
operating system


Make Reasonable Choices
‣ Choose your OS for performance and
  maintainability, not security.

‣ Keepin...
hardware

 Does Your Choice Of Gear Effect
      Your Security Posture?


‣ Nobody writes exploits for SPARC, so that’s
  ...
network

                   Firewalls
    or: Filtered Packets Are My Favorite Packets



• Learn, live, and love pf.
• It...
network


                    SSH

‣ Run it on a high port.
‣ Use key-based authentication.
‣ You’ve seen these recommenda...
network


IDS, IPS, NIDS, HIDS, and BS

• Captain! They’re breaching the hull!
• Do you have time to follow up on every ha...
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 lik...
Side Channels
‣   Google hacking
    it’s a thing, and it works

‣   owning your repository
    where’s your code at?

‣  ...
More Stuff They’re Using
‣ BiDiBLAH - it does everything
‣ Qualys - for the suits
‣ Metasploit - oh noes! the bad guys hav...
Recommendations

‣   Security by convention, not configuration
    (it’s supposed to be the Rails way!)
‣   Build security...
Resources


‣ Open Source Web Application Security Project
‣ Web Hacking Incidents Database
‣ Not the Rails wiki so much.....
Fin.

You can grab a PDF of this talk at
http://al3x.net/securing_rails.pdf


         Questions?
Upcoming SlideShare
Loading in...5
×

Securing Rails

3,304

Published on

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

Published in: Technology, Economy & Finance
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,304
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
42
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Securing Rails"

  1. 1. Securing Rails A Whole-Stack Approach RailsConf Europe 2006 Alex Payne www.al3x.net
  2. 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. 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. 4. Talks Without Code Suck ‣ This is one of those talks. ‣ Sorry. ‣ There’s no magic code-bullet for security (acts_as_impenetrable?)
  5. 5. Key Concepts ‣ Trust. ‣ Security by convention. ‣ Mitigation, not prevention. ‣ You’re as vulnerable as you are valuable. ‣ The holistic approach.
  6. 6. The Whole Stack your Rails app web server database operating system hardware network physical facilities
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. Interlude: What Are They Using at the web app/HTTP/DB layer ‣ Nikto ‣ WebScarab ‣ Firefox - with the right extensions
  19. 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. 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. 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. 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. 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. 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. 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. 26. physical facilities Access Control ‣ Biometric? ‣ Keys, cards, tokens? ‣ Handling money? Demand multi-factor!
  27. 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. 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. 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. 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. 31. Resources ‣ Open Source Web Application Security Project ‣ Web Hacking Incidents Database ‣ Not the Rails wiki so much... let’s change that!
  32. 32. Fin. You can grab a PDF of this talk at http://al3x.net/securing_rails.pdf Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×