Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
193 lines (188 sloc) 9.72 KB

Securing the Rails

Securing the Rails

What we’re going to cover

  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • SQL injection
  • Session management
  • Mass assignment
  • Exception handling/notification
  • Static analysis tools
  • Where can you learn more?

What we’re not going to cover

  • Physical security of your servers
  • Operating System security
  • Configuration management
  • Compliance concerns

This sounds like a lot, but you get a lot for free!

Cross Site Scripting (XSS) Basics

  • A User injects executable code into your application
curl -d "user[name]=<script>alert('xss');</script>" \
  • Your application saves it
  • When your application renders that information the code is executed

Possible outcomes of a successful XSS attack

  • Cookie theft
  • Session hijacking
  • Redirection of user data to an untrusted source
  • Defacement of your application
  • Denial of service

What should you do?

  • Kick back and enjoy a frosty beverage!
  • Rails 3+ automatically escapes output for you
  • Unless you tell it not to
  • But be careful of 3rd party libraries!
  • Always audit your inputs for potential holes
  • If you are on Rails 2, install the rails_xss gem
  • You can accomplish the same thing by adding h() calls to all of your templates
    • Pro Tip: Don’t do this, you will fail.

Cross Site Request Forgery (CSRF)

  • Let’s say you are a bank, and a customer is logged in
  • When that customer visits an embedded tag makes a request to your application on behalf of the user
<script type="text/javascript">
          type: 'POST',
          url: '',
          crossDomain: true,
          data: '{"from":"youraccountnumber",

Possible outcomes of a successful CSRF attack

  • Any action an authenticated user can take is able to be performed on behalf of that user by a malicious agent
  • Example: Working with Rails recommendations circa 2008

What should you do?

  • Again, relax, knowing that Rails has your back on this one
  • Make sure the option is set in the the application configuration that enables this
  • Check again that this option is set
protect_from_forgery :secret => "123456789012345678901234567890..."
  • Flag any changes to the file that contains this option and audit the changes to ensure it doesn’t get turned off

SQL Injection

  • These attacks try to manipulate the your applications data or expose data that a user wouldn’t otherwise have access to.
  • It is normally a pretty easy attack to pull off, but can get complicated in certain situations
SELECT * FROM users WHERE login = '' OR '1'='1'
  AND password = '' OR '2'>'1' LIMIT 1
  • This could be introduced by doing the following inside of a rails application
User.first("login = '#{params[:name]}'
           AND password = '#{params[:password]}'")

Possible outcomes of a successful SQL injection attack

  • Unauthorized access to data
  • Tampering with data
  • Defacement of your system

What should you do?

  • This type of attack is pretty much covered by Rails
  • If you use standard Active Record calls, everything is properly escaped for you
  • Normally, params are also escaped by default
  • You have to work pretty hard to introduce a SQL injection hole in your application

Session Hijacking/Replay

  • Once a user is authenticated against your system, the session is their stamp of entry. If another person gets a copy of the session details (the cookie), they can present this to the sytem to gain the same access that the real user has to the system
  • Unfortunately, this is really easy to do
  • If your cookies travel over plain text (HTTP vs HTTPS), then all it takes is for a user to be on a public network while they log into your system
  • This is also possible via an XSS attack

Possible outcomes of a successful Session hijack

  • The attacker will have access to anything a the hijacked users session permits
  • If this is an admin account, the impact can be huge

What should you do?

  • Protect your login and cookie transfer by forcing it to travel over SSL
    • This will require you to purchase an SSL certificate and set it up on your server(s)
MyApp::Application.config.session_store :cookie_store,
  :key => '_my_app_session',
  :secure => Rails.env == 'production',
  :httponly => true,
  :expire_after => 60.minutes
  • See XSS section

A note about cookie based session storage

  • As a general rule of thumb, you should only store data that is absolutely critical to maintain the state of your application
  • In other words, don’t put anything but a user id in your session data
  • Rails cookie store data might look encrypted, but it is only base64 encoded, making it very easy to decode the information once it is stolen

Mass Assignment

  • This is what happened to Github recently
  • Given a model with unrestricted attribute accessibility, it is possible for a user to modify attributes that should not be accessible.
  • Example
  • While this seems harmless, think of the follwing post data
curl -d "user[admin]=true" http://localhost:3000/user

Possible outcomes of a successful mass assignment attack

  • An attacker can disrupt data integrity
  • An attacker can escalate permissions and control the system
  • If you user model is tied directly to a directory platform (think Active Directory), they can gain access to your network and servers as well

What should I do?

  • Fortunately this is quite easy to protect against
class User
  attr_accessible :name, :email, :phone

Exception Handling and Notification

  • When mistakes surface as exceptions, it is important to record them
  • If a user is able to trigger an exception by acting on your system, it says a lot
  • If an attacker sees this behavior, they will focus harder on that area of your system looking for a way in
  • When you record exceptions, it is usually done via a system that will notify you that the exception occurred
    • Examples: Airbrake, Exception Notifier
  • While these tools offer advantages, they also present additional potential security holes
  • If exception data is sent in plain text, it can be stolen and used against you
  • If you are using a 3rd party service, your exception data is only as safe as their systems

Possible outcomes of improper exception handling/notification

  • Attackers gain information about your system and use it against you as they form more focused attacks
  • Users perform denial of service (DoS) attacks against your system by triggering floods of exceptions, which are expensive to process

What should you do?

  • Test! I’m not talking about unit testing here, I mean get people to actually click around any try to produce exceptions
  • Monitor your logs for exceptional situations and fix them immediately, no matter how insignificant they seem
  • If you are using a third party system, ensure that your data is travelling over SSL
  • If you are using a third party system, determine the risk of access to your data via a breach in their system
    • Essentially, is it ok if someone else owns that data?

Static analysis tools

  • These tools can look at your code and check for potential vulnerabilities
  • file:brakeman-all.png
  • file:brakeman-mass.png
  • file:brakeman-xss.png
  • file:brakeman-misc.png

Where can I learn more?

  • OWASP WebGoat project
  • Web Application Hackers Handbook
  • Practical Software Security
  • Practice Practice Pratice!