This document discusses various security vulnerabilities in Ruby on Rails applications including session hijacking, CSRF, mass assignment, and SQL injection. It provides recommendations to address these issues such as using SSL, adding session expiration, sanitizing user input, and using parameterized queries. The key takeaway is that security must be an ongoing process as new vulnerabilities emerge, and failing to address issues can enable catastrophic attacks on applications and user data.

1. Security On Rails
David Paluy
October 2012

2. "Ruby is simple in appearance,
but is very complex inside,
just like our human body."
Yukihiro "matz" Matsumoto

3. Agenda
● Session Hijacking
● CSRF
● Mass Assignment
● SQL Injection

4. Websites are all about
the data!

5. When is a user not a user?

6. You have no way of knowing
who or where the data that hits
your application is coming
from.

7. Session Hijacking

8. Session Hijacking
● Sniff the cookie in an insecure network.
● Most people don’t clear out the cookies after
working at a public terminal
● Cross-Site Scripting (XSS)
● CSS Injection
● Header Injection

9. config.force_ssl = true
● If you have http assets on an https page, the
user’s browser will display a mixed-content
warning in the browser bar.
● Rails does most of the work for you, but if you
have any hard-coded “http://” internal-links or
images, make sure you change them.

10. Session Expiry
class Session < ActiveRecord::Base
def self.sweep(time = 1.hour)
if time.is_a?(String)
time = time.split.inject { |count, unit| count.to_i.send(unit) }
end
delete_all "updated_at < '#{time.ago.to_s(:db)}' OR
created_at < '#{2.days.ago.to_s(:db)}'"
end
end

11. Provide the user with a log-out
button in the web application,
and make it prominent.

12. XSS Countermeasures
strip_tags("some<<b>script>alert('hello')<</b>/script>")
RESULT: some<script>alert(‘hello’)</script>
<%= h post.text %>
<%= sanitize @article.body %>
view SanitizeHelper

13. CSS Injection
● <div style="background:url('javascript:alert(1)')">
● alert(eval('document.body.inne' + 'rHTML'));

14. Header Injection
redirect_to params[:referer]
http://www.yourapplication.com/controller/action?
referer=http://www.malicious.tld
Make sure you do it yourself when you
build other header fields with user input.

15. Session Storage
config.action_dispatch.session = {
:key => '_app_session',
:secret => '0dkfj3927dkc7djdh36rkckdfzsg...'
}

16. Cross-Site Request Forgery (CSRF)
Most Rails applications use cookie-based sessions

17. CSRF Countermeasures
Be RESTful
Use GET if:
● The interaction is more like a question (i.e., it is a safe operation such as a
query, read operation, or lookup).
Use POST if:
● The interaction is more like an order, or
● The interaction changes the state of the resource in a way that the user
would perceive (e.g., a subscription to a service), or
● The user is held accountable for the results of the interaction.
protect_from_forgery :secret => "123456789012345678901234567890..."

18. Mass Assignment
attr_accessible :name
attr_accessible :is_admin, :as => :admin

19. Mass Assignment

20. SQL Injection
● Project.where("name = '#{params[:name]}'")
SELECT * FROM projects WHERE name = '' OR 1'
● User.first("login = '#{params[:name]}' AND
password = '#{params[:password]}'")
SELECT * FROM users WHERE login = '' OR '1'='1' AND
password = '' OR '2'>'1' LIMIT 1

21. SQL Injection Countermeasures
● Model.where("login = ? AND password = ?",
entered_user_name, entered_password).first
● Model.where(:login => entered_user_name,
:password => entered_password).first

22. Tools
● Brakeman - A static analysis security
vulnerability scanner for Ruby on Rails
applications
● RoRSecurity – explore Rails security
● Techniques to Secure your Website with RoR

23. Summary
The security landscape shifts and
it is important to keep up to date,
because missing a new vulnerability
can be catastrophic.