Slide 1
Slide 1 text
Ruby on Rails
Application Security
Anthony Lewis – @anthonylewis
Slide 2
Slide 2 text
Overview
Top Five Vulnerabilities
Mass Assignment
Definitions, Examples & Solutions
Rails 3.1 Features
https://github.com/anthonylewis/hackme
Slide 3
Slide 3 text
Injection
Still the most common way to get hacked
Slide 4
Slide 4 text
# don’t do this...
def self.authenticate( username, password )
where( "username = '#{username}' " +
"AND password = '#{password}'" ).first
end
SQL Injection?
Slide 5
Slide 5 text
So Far So Good
User.authenticate( "tony", "secret" )
=> # nil
SELECT * FROM "users" WHERE (username = 'tony'
AND password = 'secret') LIMIT 1
SELECT * FROM "users" WHERE (username = 'tony'
AND password = 'wrong') LIMIT 1
Slide 6
Slide 6 text
Magic Words
‘ OR ‘1’=’1
Slide 7
Slide 7 text
Uh Oh
User.authenticate( "' OR '1' = '1",
"' OR '1' = '1" )
=> #
Slide 8
Slide 8 text
# array conditions
def self.authenticate( username, password )
where( "username = ? AND password = ?",
username, password ).first
end
Injection Solutions
# hash conditions
def self.authenticate( username, password )
where( :username => username,
:password => password ).first
end
Slide 9
Slide 9 text
Cross-Site Scripting
Also known as XSS
Slide 10
Slide 10 text
Definition
A vulnerability that allows attackers to
inject client-side script into web pages
viewed by others
Slide 11
Slide 11 text
Rails - Safe by Default
Thankfully, Rails 3 HTML escapes all
output by default.
But what if your application needs to
show unescaped output?
Slide 12
Slide 12 text
Some people, when confronted
with a problem, think ‘I know, I'll
use regular expressions.’ Now
they have two problems.
“
– Jamie Zawinski
Slide 13
Slide 13 text
Many have tried to write a regex that
removes bad HTML.
Most have failed, often spectacularly.
Slide 14
Slide 14 text
Sanitize
Rails includes a whitelist-based filter to
remove all potentially dangerous tags
and attributes from user input.
The sanitize method is easy to use and
thoroughly tested.
Slide 15
Slide 15 text
Usage
sanitize "
Fooalert('Bar')
" => "Foo
" sanitize "ript>alert('Bar')" => "" sanitize "Foo
", :tags => %w(a b i) => "Foo"Slide 16
Slide 16 text
Broken Authentication
& Session Management
They let sheep in Starbucks?
Slide 17
Slide 17 text
Hashing
Passwords should always be encrypted.
A hash is a one-way encryption. Once
encrypted, the original password cannot be
recovered.
If a site e-mails you your password, they’re
doing it wrong.
Slide 18
Slide 18 text
bcrypt
bcrypt is highly recommended.
bcrypt includes a work factor to adjust its
speed as hardware continues to get faster.
bcrypt also has built-in salts to prevent
rainbow table attacks.
Slide 19
Slide 19 text
bcrypt in Rails 3.1
Rails 3.1 includes secure encryption in
ActiveModel::SecurePassword
Add a string field to your model called
password_digest
Call class method has_secure_password
Slide 20
Slide 20 text
bcrypt in Rails 3.1
Passwords are encrypted with bcrypt
and stored in password_digest
Adds authenticate instance method
that takes the unencrypted password as
a parameter
Slide 21
Slide 21 text
bcrypt in Rails 3.1
class User < ActiveRecord::Base
has_secure_password
validates :password,
:presence => { :on => :create }
end
Slide 22
Slide 22 text
Session Hijacking
Stealing a session ID allows an attacker to
impersonate another user.
The free Firefox plugin Firesheep makes this
one-click easy.
Slide 23
Slide 23 text
Firesheep
Slide 24
Slide 24 text
Solutions
Always use SSL.
Set an expiration date for sessions.
Destroy sessions when users log out.
Slide 25
Slide 25 text
SSL in Rails 3.1
To ensure that a controller is always
accessed with HTTPS, we add a call to
the force_ssl class method.
To restrict this to only certain actions,
we can use the :only or :except options.
Slide 26
Slide 26 text
SSL in Rails 3.1
class ApplicationController < ActionController::Base
protect_from_forgery
# always use SSL
force_ssl
end
Slide 27
Slide 27 text
Insecure Direct
Object References
Users will play with your URLs
Slide 28
Slide 28 text
Authorization
Authentication != Authorization
Authentication identifies a user.
Authorization specifies what they can
access within the application.
Slide 29
Slide 29 text
Restrict Access
def update
# user can update any post
# by manipulating the URL
@post = Post.find(params[:id])
...
end
Slide 30
Slide 30 text
Restrict Access
def update
# user can only update
# their own posts
@post = current_user.posts.find(params[:id])
...
end
Slide 31
Slide 31 text
CanCan
CanCan is a role-based authorization
plugin by Ryan Bates.
Authorization can be enforced in the
Model, View, and Controller.
There is (obviously) a RailsCast covering
exactly how it works.
Slide 32
Slide 32 text
Cross-Site
Request Forgery
Also known as CSRF
Slide 33
Slide 33 text
Definition
CSRF is almost the opposite of XSS
It exploits the trust that a site has in an
authorized user
Tricks the victim into submitting a
request to another site
Slide 34
Slide 34 text
Slide 35
Slide 35 text
CSRF Prevention
Never use an HTTP GET request to
change state
Include a secret, user-specific token in all
requests which change state
Slide 36
Slide 36 text
CSRF Prevention
class ApplicationController < ActionControll...
protect_from_forgery
end
...
<%= csrf_meta_tag %>
Slide 37
Slide 37 text
Mass Assignment
A Rails-Specific Problem
Slide 38
Slide 38 text
Definition
Model methods update_attributes and
new accept a hash of attributes and will
set or update them all attributes by
default.
Slide 39
Slide 39 text
# by default a user can set any
# attribute in the user model
@user = User.new(params[:user])
# by default a user can update any
# attribute in the post model
@post.update_attributes(params[:post])
Mass Assignment
Slide 40
Slide 40 text
Never Trust User Input.
Slide 41
Slide 41 text
Seriously.
Slide 42
Slide 42 text
The Exploit
An attacker will use Firebug to edit your
form and add fields in seconds
A clever attacker will use a tool like
cURL to automate sending their data to
your update action
Slide 43
Slide 43 text
Restricting Access
attr_protected specifies attributes that
are not accessible via mass update
attr_accessible specifies attributes
that are accessible via mass update
Always prefer the whitelist approach
Slide 44
Slide 44 text
Rails 3.1 Adds Scopes
Add :as => :admin to specify attributes
that are accessible in the admin scope
The user controller will remain the
same and the scope will be applied in an
admin controller
Slide 45
Slide 45 text
Accessible With Scope
class User < ActiveRecord::Base
attr_accessible :username, :password
attr_accessible :username, :password, :role,
:as => :admin
end
# in the admin controller
@user = User.new(params[:user], :as => :admin)
Slide 46
Slide 46 text
Disabling Protection
In Rails 3.1 you can completely disable
attribute protection
This could be useful in an import script
where you control the incoming data
Slide 47
Slide 47 text
Disabling Protection
# in an import action or script
@user = User.new(params[:user],
:without_protection => true)
Slide 48
Slide 48 text
In Closing...
• Security is a functional requirement
• Test security – success and failure
• Prefer whitelists to blacklists
• Never Trust User Input
• Keep up-to-date on security issues
Slide 49
Slide 49 text
OWASP
• Open Web Application Security Project
• OWASP Top 10 - 2010
• OWASP Secure Coding Practices Quick
Reference Guide
• Lone Star Application Security Conference
(LASCON)
Slide 50
Slide 50 text
No content