Moves On Rails: Tag rails

User Authorization in Rails

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Wed, 22 Oct 2008 10:51:00 +0200

A lot of rails apps use some form of user login. Usually a user identifies itself by entering a username/password combination into a form. The application will then check the combination and use the session of the user to store which user authenticated for that session.

Plugins like acts_as_authenticated give a nice starting point, but must applications write authorazation themselves as it is quite simple to do in Rails. If you have done this too, then here are a number of security points which such login process should take into account.

Brute forcing

Rails apps are usually tweaked to respond to requests as quickly as possible. If a response is slow, it will block my mongrel! This makes Rails apps a very good partner for the brute forcing of passwords. Action against this is surprisingly simple. You can count the number of incorrect login attempts. If this becomes more then 10, let the user enter a captcha. Or really degrade the login by rejecting every login attempt with a 403, when the last incorrect login attempt was less then two or three seconds ago.

HTTP login posting

Many sites offer a login box on their front page. This is a very user friendly and I would be the last person to tell you not to do this. However, this often means that you are letting a user authenticate over HTTP, which is not very secure. Anyone snooping the traffic of that user will see a plaintext username and password being posted to your site. Poke around with Webscarab or Firebug in Firefox to pick up on these things easily.

Solutions are again easy. If you have a HTTPS part of your site, make sure the login form posts to it. If you do not have HTTPS, you can encrypt the password in the clients browser with javascript via a public/private key combination. A lot of good examples of this can be found all over the internet.

Session hacking

At the moment Rails supports two types of sessions. It can reside serverside in a file or database and clientside in the cookie of the client.

We will first discuss the server side session, as this was the default before Rails 2.1. When a user connects to your website, he will automatically receive a unique session id. This is is the only thing your application can use to distinguish between unique users and their requests. The default session ids in Rails are generated correctly, so that is very hard for someone to guess ids of other users using your application. But if a hacker does acquire a session id of another user, Rails will not offer you any protection by default. And there actually quite a few ways for a hacker to obtain session ids of other users. The two most commonly used being: Cross Site Scripting exploits (XSS) and code injection.

Why is this a problem? Well if an attacker shares a session id with another user, and that user logs in, the attacker will share their session. This means that the attacker will have the same privileges as the user. Countering this can be a bit of a hassle, but as every application is sure to have a XSS exploit somewhere, it is a hole that is important to plug.

First you need to reset sessions after a logon. This will counter any creatively crafted URL attacks. Secondly it is a good idea to fixate your sessions on the ip used in the login attempt and you also should take a look at sesion expiration.

Clientside sessions have the same problems, so don't count on them as being the ultimate solution.

SQL injection

Initially I wanted to leave this out, i as the problem is still so common, I decided to have it here anyway. Rail does provide you with SQL injection protection, but you still have to use it correctly in order to be safe.

User.find(:conditions =>
   ["username = #{username} AND password = MD5(#{password})"])

User.find_by_username_and_password(username, SHA(password))

They both work, but the first one can be easily exploited through SQL injection.

Conclusions

This will not magically fix all your user authorization problems, but it should point you in some interesting directions. Want to read more? Here are a few good places to start reading.

http://guides.rails.info/securingrailsapplications/security.html http://www.rorsecurity.info

Nested include has major memory leak (Rails 2.0.1).

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Wed, 02 Jul 2008 15:59:00 +0200

As our mongrels were using up quite a lot of memory, so I tried to figure out what was causing this.

When running the app locally I found out that one certain page caused the mongrel to grow from 60 to 190 megabytes. A whopping 130 megabytes!

After commenting out some of the code, I realized that a single line was causing all of the memory usage

contracts = Contract.find( :all, 
  :conditions => ['contracts.employee_id IN (?) ', employees ],
  :include => [:expertise_profile => :qualifications ] )

Ouch! The nested include of rails somehow leaks a large amount of memory. The fix was a piece of cake.

contracts = Contract.find( :all, 
  :conditions => ['contracts.employee_id IN (?) ', employees ],
  :include => :expertise_profile )

Now my mongrel stays at 60 megabytes. I don't know if this issue persists in the new 2.1 Rails, but I'll check that soon!

Testing your Application Controller with rSpec

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Wed, 23 Jan 2008 14:25:00 +0100

I was trying to create a function that would check the enforcement of the before filters in my application controller. After going through a lot of rspec documentation and examples, I found nothing that really suited my needs. After a long google, I found a mention in the rspec mailing list and a hint to a solution for this. This is a working example of this idea.

I have in my application controller the following code:

class ApplicationController < ActionController::Base
  before_filter :check_authorization
   ....
  # Checks if a user is authorized
  def check_authorization
    User.check_authorization(controller_name, action_name)
  end
end

And in spec/controllers/application/application_spec.rb the following description.

describe "an authorized controller", :shared => true do

  it "should have the check_authorization set in the before filter" do
    ApplicationController.before_filters.should \
      include(:check_authorization)
  end   
end

In all other controller specs I can now do this:

require 'application_controller_spec'

describe UnitsController, "in general" do
  it_should_behave_like "an authorized controller"
end

By doing this I now have a spec that ensures that every controller checks authorizations before doing anything else. How cool is that :)!

It would be nicer if the test handled skip before_filters in some nice way like: it_should_behave_like "a monkey".except_for_action('show'). Has anyone got any ideas for that?

Special thanks to Matthijs Langenberg for his insights.

Moving to 2.0

andre.foeken@movesonrails.com (Andre Foeken) — Thu, 18 Oct 2007 15:15:00 +0200

Issues found so far:

Lots of small routing changes. Thank god for grep! : addresses_path(@employee) => employee_addresses_path(@employee) . (Don't forget the *_url methods!)
Several plugins failed due to extract_options_from_args!. This method has been replaced with the nicer: args.extract_options! (i.e acts_as_paranoid, acts_as_mappable, paginating_find)
acts_as_paranoid had minor issues: fix by replacing construct_count_with_legacy_args to construct_count_options_from_args
ActiveResource is now part of rails core. Be sure to freeze edge twice if you are upgrading from 1.2.3 or lower. All of our libXML additions had to be redone. (this time through /patches, tnx fngtps)
Different behavior of the render method. Before you could call render "addresses/show" if you wanted to, this has been changed to render :template => "addresses/show". This affects several plugins too (like rspec_on_rails)
We no longer need the mysql_tasks plugin, since this functionality is now build right in!
redhillonrails_core has some issues with connection adapters. Apparently rails 2.0 no longer loads adapters it doesn't need. This creates some issues with the redhills plugin since it tries to include stuff in those adapters. Adding a begin/rescue block around each include solves the issue.
The development environment no longer needs the config.breakpoint_server = true setting.
Polymorphic models are now saved with the base class as type in external objects.
Autocomplete textfields are now a plugin: ./script/plugin install auto_complete
If you have overridden the to_json methods, be sure to change that to to_json options={}, else they might fail.
Migrations no longer working? Try removing duplicate names. We have two migrations with the same name (but different id) and it just skipped the first one (!)

Benefits so far:

Speed! We did expect some speed increase, but this is major! Our pdf generating stuff uses a lot of ActiveRecord and we saw decreases of more than 50% request time.

Rails Security

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Thu, 20 Sep 2007 19:28:00 +0200

After a security presentation at RailsConfEurope 2007, I found a lot was missing, so I made this. I didn’t finish it in time for reject conf, so I posted it here. Now it's time for me to go on vacation! See you next week!

Gettext Generators 1.2.3 Released

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Tue, 28 Aug 2007 20:41:00 +0200

The longawaited update for the Gettext Generator.

First release as plugin
Added svn:merge raketask
Updated generated resource to mimmick scaffold_generator packaged with rails 1.2.3 tag

So go to RubyForge or take a look here.

I'm currently getting the plugin uploaded to rubyforge. As soon as I have that figured out how that works, I'll post the link here.

ruby script/plugin install svn://rubyforge.org/var/svn/gettextgnrtrs/tags\ /Gettext-Generators-1.2.3/