Security Problem with authenticate_with_http_digest

A security problem has been reported with the digest authentication code in Ruby on Rails. This vulnerability can allow users to bypass your password protection. This vulnerability has been publicly disclosed on several websites, users are advised to take the mitigating steps described below immediately.

The issue comes from the handling of the block passed to authenticate_or_request_with_http_digest. This block must return the user’s password in the clear, or a sha1 hash of the user’s password. Unfortunately the documentation was unclear on this and the examples cited would return nil if the user was not found. The correct behaviour if the user doesn’t exist is to return false.

If the return value was nil, rails proceeded to verify this value against the provided password. Because of this an attacker can provide an invalid username and no password and authentication will succeed.

Fixed Versions

We have altered the behaviour of the relevant code to make nil an authentication failure. This fix has been pushed to 2-3-stable and will be present in 2.3.3 due to be released in the next few days. All versions of edge rails after commit 1ad57cfe2fbda58439e4b7f84008ad23bc68e8b0 contain the fix.

Steps to Protect your application.

Users can protect themselves without upgrading by simply ensuring that their authentication blocks never return nil. To take an example from the documentation:

authenticate_or_request_with_http_digest(REALM) do |username| USERS[username] end

Should instead be something like:

authenticate_or_request_with_http_digest(REALM) do |username| USERS[username] || false end

Disclosure Notes

Due to communication difficulties and a mis-understanding between the reporter and the security team. This vulnerability has been publicly disclosed on several websites, users are advised to update their applications immediately. Steps are being taken to ensure that the security email is more reliable in the future. We regret the nature of this disclosure and will endeavor to ensure it doesn’t happen again in the future.

Community feedback for the future of Rails

A few months ago, we announced the creation of a “forum” to discuss the future of Rails and what the community is interested in. Since then, many important suggestions/topics were addressed, many features were completed or started. My goal in this post is to give you a quick overview on the status of the uservoice forum.

rails uservoice

##Suggestions mentioned and completed:

  • Nested Model forms This is something that was actually started before we put the forum together and this feature is now available since Rails 2.3.x

  • Rails magazine Olimpiu Metiu already released two issues of his Rails Magazine. The PDF versions are available for free but you can also purchase the print version.

  • Better Wiki A lot of people have put efforts in building the new wiki and I’m sure a lot more content will be provided. We have also made the wiki available for translation.

##Accepted/started suggestions:

  • Improved performance This is something that already started in the Rails3 branch, go check the work done by Josh, Yehuda, Carl and others to make Rails perform even better.

  • Public and plugin API This is something that’s particularly important for 3rd party developers and therefore plugin users. There is still a lot of work to be done with 3rd party developers and “advanced users” before we can get a fixed API. However, once we will have this API, Rails updates and plugin compatibility should be much smoother.

  • Slices/Engine Rails 2.3 came with the ability to have engines in your plugins and if you were at RailsConf, you might have attended Yehuda and Carl’s talk on mountable apps. Thanks to some work done on the router and Action Controller, you should be able to mount a Rails app inside another one sometime in the future.

  • Easier to read code The refactoring has already started and the internal code should be cleaner and easier to read. Remember that Rails is 5 years old, such a task isn’t easy.

  • Better support for non relational databases Thanks to Action ORM and some more refactoring, non RDBMS and other data stores will be better supported.

  • Unbind Test::Unit and Prototype Agnosticism is a big theme in Rails 3. Even though, Test::Unit and prototype will be the default, Rails won’t make any assumptions about users using one framework or the other. Watch David’s keynote at RailsConf for more information.

  • Make Action Mailer consistent with regular controllers This task was started as part of the work done on Abstract Controller.

Don’t forget that you can still make your suggestions and/or pick one that is already listed and start working on it!

New code contributor index

Xavier Noria (code) and José Espinal (design) have created an awesome code contributor index for Rails core submissions. It’s being updated automatically every night and tracks the number of commits and which particular commits to individuals in the community. You can even track the commits over time, as in who’s been most active this month.

The site now lives at Thanks to Xavier and José for putting in the work on this!

Railsconf 2009 in Review

Railsconf wrapped up last week, and I think we all survived Vegas. If you weren’t able to make the conference, there is plenty of video, slides, and blog entries to get a taste of what went on.

First up you can get a summary of the conference by checking out my Railsconf in 34 minutes video. Thanks to O’Reilly you can also watch all the keynotes, the Rails Core panel, the Women in Rails panel, and the Ruby Heroes Award Ceremony. I also put together a few videos during the conference which were played before the Keynotes (Tutorial Day, Tuesday, Wednesday, and a demo of Rubystein thanks to the guys from Phusion).

If you’re looking for written material, the slides are available online and you can find a great list of blogs here which covered the event.

Unfortunately the sessions at the conference weren’t recorded, but we’re really hoping that this is the last year that happens.

More speakers on RailsConf Vegas

RailsConf is going down next week in Vegas. I’m sure it’s going to be a great show and can’t wait to get out there. A few of the presenters have been blogging about the presentations that they’re doing.

Alexander Dymo is doing a session on Advanced Performance Optimization of Rails Applications, Jason Rudolph has one on testing JavaScript in Rails projects, Pat Maddox is talking about dealing with legacy Rails projects, and finally Sean Schofield just has five good reasons to attend the conference.

Check out the entire schedule for the conference and signup if you haven’t already. See you in Vegas!

This Week in Edge Rails

April 18, 2009 – April 24, 2009

Edge Rails has been undergoing major surgery for the past week, as the core team gets ready for a Rails 3.0 alpha release at RailsConf. We saw about 50 commits to the master branch in GitHub this week. Here’s a quick overview of the recent changes.

Rails 2.3.x Changes

Before digging into the changes on the master branch, there were a few things committed to the 2-3-stable branch. If you’re running on 2.3 edge, these are ready for you; they’re also ported to the master branch already.

  • A couple of bugs involving associations with hash conditions have been fixed, notable to make sure that :dependent => :delete will work.
  • The PostgreSQL Active Record adapter now does the right thing if you use tables in non-default schemas. You need to set the table name in your model class, of course: set_table_name 'other_schema.customers' commit
  • Also in the PostgreSQL adapter, a couple of bugs related to wrong quoting of names with capital letters are fixed.

ActionView::Path Refactoring

One major chunk of change in Rails 3 this week comes from the continued work to refactor Action Pack. This time, ActionView::Path was the target. Changes in commit include decoupling ActionView::Path from Action Controller and Action Mailer, which gives us two major benefits. First, consolidating similar code in one place makes it easier to understand and maintain. Second, by abstracting this stuff and giving it an API, we’ll make it possible for other components to participate in the controller layer, beyond mailers and traditional controllers.

There’s also some work here to set up for the future. The plan is to decouple templates from the file system, and to decouple localization from ActionView. Stay tuned!

Pluggable JSON Backends

You may recall that recently Rails went to pluggable XML support. This week, thanks to work from Rick Olson, we have pluggable JSON. This means that you can replace the default YAML-based JSON support with the JSON gem:

ActiveSupport::JSON.backend = "JSONGem"

As part of this change, Rails now uses ActiveSupport::JSON.encode() wherever it needs JSON. This replaces using #to_json, and Rails team is recommending that you do the same. If you do choose to use #to_json, you need to be aware that some libraries might override it. You can use this pattern to make sure that you’re getting Rails’ own definition of #to_json:

gem 'json'
# JSON gem loaded, which overwrites to_json
ActiveSupport::JSON.backend = "JSONGem"

class ActiveRecord::Base
  # replace the gem's to_json with Rails' own to_json
  alias to_json rails_to_json

Active Support à la carte

In Rails 2.x, require "active_support" pulls in all core extensions at once. In Rails 3, require "active_support" only makes the extensions available; you have to explicitly require those you wish to use. Many of this week’s changes were concerned with breaking up Active Support so you can take just what you need and nothing more.

The end result is that it’s easy to cherry-pick features from Active Support without feeling like you’ve invited a portly gentleman for a piggyback ride. As an added bonus, all core extension documentation is now consolidated in one place: the core class. You don’t have to go poking around every extension module to find a method.

Internally, the core extensions have been reorganized so they can be directly required without assuming all of Active Support is available. Want inflections like "car".pluralize? require "active_support/core_ext/string/inflections" and you’ve got them. Note: the implementation and organization will change as we settle on the best way to provide core extensions.

Other Edge Changes

  • The Rails extension to Pathname was dropped, since it was only used in one spot in the code. commit
  • Support for the DRb cache store has been removed. commit
  • The sqlite Adapter joins the PostgreSQL adapter in supporting microsecond resolution. commit

2009 Rails Google Summer of Code Projects

The Google Summer of Code program has announced this year’s funding winners, and Rails has four student slots. Here’s what our students will be working on this summer:

Joshua Peek will be refactoring some of the Rails internals, with the goal of finishing the work on Active Model. The idea behind this particular Rails component is to extract some of the commonalities from Active Record and Active Resource, which in turn will make it easier to maintain the higher-level components and make the more consistent.

Nelson Crespo is planning on adding some Dtrace probes into a Rack module. These probes should make it possible to see what’s going on in a Rails application (or any other Rack-based application) with much finer detail than can be easily retrieved now. When the probes are ready, he’ll be working up some visualizations.

Jose Valim is tackling a rewrite of the Rails generator code. Right now, the generators are tightly-coupled to particular architectural choices; the goal is to make it possible to select, for example, a testing library, an ORM, and a Javascript library when you choose to generate a scaffold, and have the generated code use your preferred pieces.

Emilio Tagua will be working on Active Relation. This is another refactoring of the ActiveRecord code, covering the query generation capabilities. With Active Relation as a separate component, Rails will be better positioned to move towards ORM agnosticism.

We’d like to thank all of the students and mentors who participated in the Summer of Code selection process – it was tough to get down to four projects, considering all the great proposals we had. In particular, we had six runners-up whose proposals were excellent: Carlos Kirkconnell, Florian Gross, Hector Gomez, Ian Ownbey, Luciano Panaro, and Daniel Luz. We’re looking forward to seeing what all of our students bring to Rails this summer, and hope not to lose touch with others who are also excited about the prospects for Rails 3.0.

This Week in Edge Rails

April 4 – April 17, 2009

Just in case you missed the news: edge Rails is waking up, with Rails 3 changes starting to show up in the master branch at Github. So there’s a lot to discuss this week. If you want some more of the technical story on the Rails 3 rearchitecting to date, check out the detailed blog postings from Yehuda Katz.

Which Branch Should I Use?

The Rails 3.0 work is being done on the master branch in the Rails repository on Github. If you want to keep up with all the latest changes, this is the branch to track – with the caveat that this is currently alpha code. It’s entirely possible to build a working Rails application using the master branch. The Rails core team is committed to keeping the master branch passing all tests, and in fact improving our test coverage and continuous integration policies are both on tap as Rails 3 improvements. But it’s important to realize that the changes to Rails will result in many plugins needing a rewrite before they will work with Rails 3 (of course, some plugins will need more updating than others). This will make Rails 3 difficult to use for full-scale production deployments for some time to come.

For existing production applications, you should be tracking the changes on the 2-3-stable branch at Github. This branch contains bug fixes and improvements to the 2.3 release code, and should continue to remain compatible with the plugins and code that you’re already using.

Should I be Submitting Patches to Rails?

Absolutely! Rails has always been a community effort and that’s not changing for Rails 3. We welcome patches for either Rails 2.3 or Rails 3.0 – please use the appropriate tag (2-3-stable or 3.0) in your Lighthouse tickets to make it easy to tell which branch you’ve tested and based your patch on. The Contributing to Rails Guide will help you through the mechanics of submitting a patch to Rails.

David outlined the overall vision for Rails 3 back in December, and that’s still the basic plan. If there’s some piece that you’d especially like to get involved with, the Ruby on Rails: Core mailing list will help you get in touch with the developers to coordinate plans – and possibly save some headaches. Most of the major pieces of work are already underway, but we know that community ideas and contributions are essential to the success of Rails 3.

Rails 2.3.x Changes

Speaking of Rails 2.3, the last couple of weeks have seen some bug fixes deployed, and one interesting piece of new functionality: ActiveRecord::Base#touch. The idea is that you get a shortcut to push the current time into the updated_at or updated_on timestamp field in a record:


What makes this more than a savings of a few keystrokes is that it’s also implemented as an option for belongs_to associations:

class Order < ActiveRecord::Base
	belongs_to :customer, :touch => :last_order_update

With this declaration in place, saving or destroying an order object will touch the corresponding parent customer object. This can come in very handy when you’re trying to invalidate a cached copy of the parent in that situation.

commit commit

Rails 3.0 Changes

ActiveRecord::Base#touch was also added to Rails 3.0 at the same time that it went into the 2.3 branch. In general, this should be the case: new functionality from Rails 2.3 will carry over into Rails 3. The core team is working hard to ensure easy upgrades and compatibility when the time comes to make the version change. But there were a lot of other changes this week that only apply to Rails 3: that’s what the rest of this posting is about.

Module Organization

There are spots in the Rails code where there are multiple levels of inclusion and inheritance and setup. As part of making it easier to follow what’s going on, Rails 3 is introducing new depends_on, use, and setup abstractions. These can make the intent of code more obvious on reading:

module AbstractController
  module Helpers
    depends_on Renderer
    setup do

module ActionController
  class Base2 < AbstractBase
    use AbstractController::Callbacks
    use AbstractController::Helpers

commit More information


Probably the biggest architectural change so far in Rails 3 is the introduction of the AbstractController base class. This is a new implementation of the commonalities between ActionController::Base and ActionMailer::Base, and will eventually serve as a base class for the Rails analog of Merb’s parts. The intent is not to provide code that plugins or applications will use directly, but the build a solid low-level API that other things can depend on. For example, a consumer of AbstractController will be able to implement its own path-finding logic for templates, or add additional options to the basic render method.

commit commit More information


Another internal architectural change is the introduction of ActionDispatch. A new member of the Action Pack family, ActionDispatch exists as a home for all of the various HTTP libraries and middleware that were previously stuffed into ActionController, including such things as request handling, parameter parsing, status codes, and our bundled copy of Rack. commit

Defining the Surface Area

One of the goals of the Rails 3 work is to cleanly distinguish between public API methods that plugins and application code can rely on, and Rails internals that are subject to change. For an example of this, you can look at some of the refactoring that’s been done to ActionView::Template. Here, the change is to identify the methods that aren’t used by other classes, and to make them private. This immediately makes the intended API of the class more graspable, and in the long run will help give us a contract with plugins as to how they should interact with core code. After the current surface area has been formally identified, it’s likely that it will be reduced to result in a cleaner external API. commit

AJAX and authenticity tokens

If you’ve been writing much javascript by hand, you’ve discovered the nuisance of needing to include the Rails authenticity token in your requests. A closer analysis of the issues shows that there’s no need for these tokens in AJAX requests, because the same origin policy protects them. So, Rails 3 no longer checks for those tokens on AJAX requests, and that’s one less ugly bit of javascript for you to write. commit

Test Improvements

Another area of focus in Rails 3 is to bring the internal tests up to current best practices. There are a number of spots in the existing code where the tests are less systematic than they could be – changes have been checked in with test coverage, but no one has gone through and tried to ensure full test coverage of all normal “happy” code paths. For a glimpse of what’s happening in this area, check out some of the test files in actionpack/test/new_base (the new_base code is a rewrite-in-progress of ActionController::Base). There’s also active work going on to improve our continuous integration story, and the get together some basic high-level integration tests that can exercise Rails as a whole.

Loose Ends

There are some Rails 2.3 features that are currently not implemented in master. Some changes could not be merged cleanly with the new architecture, others are being reimplemented in different ways. You’ll find some specifics in this commit message, but the missing pieces include the performance boost for development mode rendering, template recompiling in production, and some template-picking logic. The developers working on Rails 3 have indicated that they intend to get back to feature parity as quickly as possible. In fact, a first pass over the rails-dev-boost changes has already been committed.

Removed: CGI Support

Rails 3 will not support direct CGI dispatching. This was deprecated in Rails 2.3, so it should be no surprise to anyone that it’s being removed entirely. If you need to use CGI for some reason, though, remember that it’s still supported through Rack. commit

Phusion Announces Passenger for Nginx

In the relatively short time since its release, Phusion Passenger has become part of the preferred deployment strategy for many Rails applications. But because it’s targeted at Apache, some sites have been unable to use Passenger. Apache is a great full-featured web server, but for highly traffic nginx seems to consistently deliver better throughput at lower memory use.

As of today, though, the Rails server landscape is changing for the better once again with the announcement of Phusion Passenger for Nginx. This new version takes the Passenger technology, including the use of Ruby Enterprise Edition, and integrates it tightly with nginx. How tightly? Well, you just install the Passenger 2.2.0 gem and run the included nginx installer, and you get a custom-built version of nginx along with instructions on how to configure it to server your Rails site. In addition to combining the benefits of nginx and Passenger, this has the side effect of greatly simplifying the nginx setup.

For more details, including a screencast, hop on over to Phusion’s blog

One Giant Leap Forward

As of a few minutes ago, the first big bunch of Rails 3 changes were merged back to Rails master branch in github. This represents a good deal of work by Yehuda Katz, Carl Lerche, and others. I’ll have more to say on the changes later on this week, but for now, just a quick caution: if you’re in the habit of using Edge Rails, you should likely switch to the 2-3-stable branch for the time being. The master branch of Rails will likely take a little while to settle back into something that can be used for anything other than getting a preview of the Rails 3 excitement.