Description

We received a security report saying that it was possible to confirm records with a blank confirmation_token parameter. In order words, hitting the following URL /users/confirmation?confirmation_token= would successfully confirm a user instead of showing a validation error – e.g. Confirmation token can't be blank.

This only happens if there are records with a blank confirmation token in the database. This is because of the way the method find_first_by_auth_conditions works (which is similar to ActiveRecord’s #find_by). It is important to mention that we haven’t found a case where Devise sets confirmation_token to an empty string.

In summary, before version 4.7.1, this is what would happen after hitting the confirmation endpoint with a blank confirmation_token:

Started GET "/users/confirmation?confirmation_token=" for ::1 at 2019-09-05 10:24:29 -0300
Processing by Devise::ConfirmationsController#show as HTML
  Parameters: {"confirmation_token"=>""}
  User Load (1.0ms)  SELECT  "users".* FROM "users" WHERE "users"."confirmation_token" = $1 ORDER BY "users"."id" ASC LIMIT $2  [["confirmation_token", ""], ["LIMIT", 1]]
Code language: PHP (php)

Notice that the SQL query is trying to find users with confirmation_token = "".

It’s also worth mentioning that only unconfirmed records – i.e. with confirmed_at: nil in the database – would be confirmed in this case. For already confirmed users, a validation error (Email was already confirmed, please try signing in) would be displayed.

Possible implications

Considering that there are records with an empty confirmation_token in the database, a request sending a blank parameter would confirm the first record found in the database. This means that someone’s account would be confirmed by mistake.

A more sensible scenario is for applications that automatically sign in accounts after confirmation. That would not only confirm someone’s account but also give an attacker access to it. Although this feature is not included in Devise, we know that some applications might have it.

For already confirmed records – i.e. with a confirmed_at date in the database – the validation error would be displayed, but their email would be leaked to the end user inside the form’s input.

Solution

The solution was to validate whether the confirmation_token is empty before doing any query in the database. So now, when the same endpoint is hit, nothing happens:

Processing by Devise::ConfirmationsController#show as HTML
  Parameters: {"confirmation_token"=>""}
Completed 200 OK in 371ms (Views: 339.0ms | ActiveRecord: 5.9ms)
Code language: PHP (php)

And the end-user will see the validation error on the screen.

See the pull request with the solution for more information.

Actions you might want to take

Aside from updating Devise, you might also want to check whether you have records in that state in your application. You can do that with a query like this one:

irb(main):001:0> User.where(confirmation_token: "")
  User Load (0.6ms)  SELECT  "users".* FROM "users" WHERE "users"."confirmation_token" = $1 LIMIT $2  [["confirmation_token", ""], ["LIMIT", 11]]
=> #<ActiveRecord::Relation []>
Code language: PHP (php)

If you get results out of this query, you might want to nullify them to avoid the confirmation by mistake:

irb(main):002:0> User.where(confirmation_token: "").update(confirmation_token: nil)
  User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."confirmation_token" = $1  [["confirmation_token", ""]]
   (0.2ms)  BEGIN
  User Update (0.7ms)  UPDATE "users" SET "confirmation_token" = $1, "updated_at" = $2 WHERE "users"."id" = $3  [["confirmation_token", nil], ["updated_at", "2019-09-05 14:03:20.857488"], ["id", 1]]
   (1.2ms)  COMMIT
Code language: JavaScript (javascript)

Causes

Although we received a report where someone worked in an application that had records with a blank confirmation token in the database, no code or use case was found inside Devise that would make records end up in that state.

If you find a case where this happens, please contact us at opensource@plataformatec.com.br and we’ll look at it.

Finally, we want to thank Anthony Mangano for reporting this issue and helping with the solution.

The post Improve confirmation token validation in Devise (CVE-2019-16109) first appeared on Plataformatec Blog.

But don’t be upset, it turns out you might not need to override Devise’s SessionsController or monkey patch some of its internals. In this article, you’ll learn how to create a token-based authentication for a JSON API by relying on Warden’s features.

Disclaimers

Warden? Huh?

This article will focus on how to include custom Warden strategies in a Rails application that uses Devise. If you want to know more about Warden strategies, I gave a talk last year at RailsConf that explains them in more details.

Show me the code!

The first part of this article will show how to set up a Rails application using Devise. If you want to skip to the token authentication part, click here.

Setup

Create a new Rails application (this example uses Postgres as the database to take advantage of UUIDs to generate the access tokens):

rails new devise-token-based-auth --database=postgresql

Add the devise gem to your Gemfile:

gem 'devise'

Now run the Devise generators:

rails generate devise:install
rails generate devise User

We are going to need a column to store the api_token. For this, we’ll use the pgcrypto extension’s gen_random_uuid() function.

First, create a migration to enable the pgcrypto extension:

rails generate migration enable_pgcrypto_extension

Now edit the migration to call the #enable_extension method:

class EnablePgcryptoExtension < ActiveRecord::Migration[5.2]
  def change
    enable_extension 'pgcrypto'
  end
end

The database is now able to use pgcrypto‘s functions. Now we can create a migration to add the api_token column:

rails generate migration add_api_token_to_users

Now edit the migration like the one below. Notice the default is set to gen_random_uuid():

class AddApiTokenToUsers < ActiveRecord::Migration[5.2]
  def change
    add_column :users, :api_token, :string, default: -> { 'gen_random_uuid()' }
    add_index :users, :api_token, unique: true
  end
end

Don’t forget to create the database and run the migrations:

rails db:create db:migrate

The next step is to create a user using rails console and grab its api_token:

rails console
Running via Spring preloader in process 60784
Loading development environment (Rails 5.2.2)
irb(main):001:0> user = User.create!(email: 'bruce@wayne.com', password: '123123')
=> #
irb(main):002:0> user.reload.api_token
=> "a4839b85-4c96-4f22-96f1-c2568e5d6a7f"

It’s time to create the Warden strategy now!

The Api Token Strategy

Create a file app/strategies/api_token_strategy.rb with the following content:

class ApiTokenStrategy < Warden::Strategies::Base
  def valid?
    api_token.present?
  end

  def authenticate!
    user = User.find_by(api_token: api_token)

    if user
      success!(user)
    else
      fail!('Invalid email or password')
    end
  end

  private

  def api_token
    env['HTTP_AUTHORIZATION'].to_s.remove('Bearer ')
  end
end

In short, the strategy tries to find a user for the token sent in the Authorization header. If it does, it signs the user in. Otherwise, it returns an error. If you are not familiar with the success! and fail! methods, watch the talk on the start of the blog post to get a sense on how Warden works.

Warden needs to know about this strategy. Create a file config/initializers/warden.rb with the following code:

Warden::Strategies.add(:api_token, ApiTokenStrategy)

This allows Warden to recognise that it should call the ApiTokenStrategy when it receives the :api_token symbol.

Authenticating a user

Now it’s time to use the strategy. Create an UsersController that renders the current_user in JSON:

class UsersController < ApplicationController
  def show
    render json: current_user.to_json
  end
end

Don’t forget to add a route for this controller action. Open config/routes.rb in your editor and include the following:

Rails.application.routes.draw do
  devise_for :users
  resource :user, only: :show
end

To require authentication in the controller, the method #authenticate! should be called passing the desired strategy as a parameter:

class UsersController < ApplicationController
  def show
    warden.authenticate!(:api_token)
    render json: current_user.to_json
  end
end

You can see that this works using a simple curl request:

curl http://localhost:3000/user -H 'Authorization: Bearer a4839b85-4c96-4f22-96f1-c2568e5d6a7f'

{"id":3,"email":"bruce@wayne.com","created_at":"2018-12-26T13:45:37.473Z","updated_at":"2018-12-26T13:45:37.473Z","api_token":"a4839b85-4c96-4f22-96f1-c2568e5d6a7f"}

It is also possible to define :api_token as a default strategy so that it’s called when no strategy is passed as a parameter. Add the following code in the config/initializers/devise.rb file:

Devise.setup do |config|
   # The secret key used by Devise. Devise uses this key to generate...
   config.warden do |manager|
     manager.default_strategies(scope: :user).unshift :api_token
   end

# ==> Mountable engine configurations...
end

This will add the :api_token strategy in the first position, followed by Devise’s default strategies (:rememberable and :database_authenticatable).

Now it’s possible to use Devise’s #authenticate_user! helper, and the :api_token will still be used:

class UsersController < ApplicationController
  before_action :authenticate_user!

  def show
    render json: current_user.to_json
  end
end

Summary

And… we’re done! The focus here was to show how to include custom Warden strategies in a Rails application. The example was straightforward but you can follow this structure to create custom authentication logic to suit your application’s needs.

The entire application used in this article can be found in GitHub.

The post Custom authentication methods with Devise first appeared on Plataformatec Blog.

Devise implements the “Remember me” functionality by using cookies. While this functionality works across multiple devices, Devise ended-up generating the same cookie for all devices. Consequently, if a malicious user was able to steal a remember me cookie, the cookie could be used to gain access to the application indefinitely unless the user changed his password (which may not be a frequent event).

Although all Devise versions are vulnerable to this bug, the bug can only be exploited if the attacker can steal cookies in the first place. Regardless, we recommend all users to upgrade to the latest Devise version.

Releases

Devise 3.5.4 has been released with a fix. This release adds a timestamp to the cookie, guaranteeing cookies can be expired on a case-by-case basis instead of an all or nothing approach.

We also have made a patch available for those running on older versions.

Acknowledgements

We want to thank Alfredo Ramirez (bonds0097@gmail.com) from VSR for reporting the issue and working with us on a fix.

The post Improve remember me cookie expiration in Devise (CVE-2015-8314) first appeared on Plataformatec Blog.

I wish there was a good guide on maintaining OSS projects. I'm a maintainer of a reasonably popular project and I have NFI what I'm doing.

— Charlie Somerville (@charliesome) April 26, 2014

In between consultancy jobs and building projects for our clients, our team is directly involved in many Open Source Projects. So after exchanging some messages, I realized it would be useful to document some of the common practices we do at Plataformatec for maintaining Open Source Software.

Although this post is not a complete guide, it does share our experience of maintaining and working on the issues tracker of many projects like Rails, Simple Form, Devise, and lately Elixir.

Avoid burnout

One of the most important things when it comes to OSS is to avoid burnout. This is extremely important for small projects, which mostly depend on one or two contributors. If someone burns out in large projects, there is always someone else to take on the issues tracker and maintenance work until you gather your energy back.

For small projects though, if you need to step away, it likely means the project will go unmaintained for a while, which will just make the situation worse as issues will continue to arrive.

So a lot of what we will discuss here is meant to avoid burnout. Here are two examples:

1. Avoid issues from piling on – it is likely that, if the issues tracker has 30 open issues, you will feel less and less compelled to work on them;

2. Learn how to say “no” – merging code or features you are not a 100% comfortable with may makes thing worse. Every time there is a bug on that particular feature, you may feel less compelled to work on it or even not be willing to improve/refactor the code in the future, etc;

Of course different developers have different reasons to burnout, so whenever you find yourself lacking the energy to work on a project, try to understand why the energy isn’t there and find ways to avoid the problem from repeating in the future.

Contributing.md file

If you are hosting your project on GitHub, GitHub allows you to place a Contributing.md file with instructions on how to contribute to the project. For example, here are the files for Devise and Elixir projects.

Remember the community wants the same as you: the best for your Open Source project. So having detailed instructions on how to collaborate and contribute to the project helps both you and the community. You will have more detailed bug reports, better patches/pull requests, and other developers will find it easier to give back.

However keep in mind that there will still be incomplete or wrong reports from developers that didn’t read the Contributing.md file. That leads us to the next tip.

ABC (Always Be Closing)

If you have ever been to a sales workshop or read about how to improve your sales skills, it is very likely you have seen Alec Baldwin’s speech from Glengarry Glen Ross:

Although we are not doing any sales here, I strongly apply the concept of “Always Be Closing” to the issues tracker. I am always, actively, closing issues. Here are the main reasons I close open issues:

• The user has not read the Contributing.md and have posted a bug report without the relevant information like OS, software versions, stacktraces, etc;

• Users are asking questions on the issues tracker when a project has a specific channel for those, like a mailing list or a tag on Stack Overflow;

• The proposed feature is too complex to not be worth the time that it requires to be implemented. Or you don’t see the possibility for the feature to be implemented in a medium-term plan;

Usually the first thing I do in the morning is to give a quick pass at my inbox looking specifically at open issues. Issues that are invalid or that cannot be acted on are closed with the proper message. In case the user provides the missing information after a bad bug report is closed, the issue will be reopened in the next morning. This activity only takes a couple minutes of your morning, which you can do while you sip your hot coffee.

Soon after I adopted this workflow, Vasiliy Ermolovich noticed most of the time I was closing issues with similar reasons, and he has created the extremely useful José vs OSS project which integrates with Firefox and Chrome to help me close issues more quickly. This project has probably saved me days of work!

Ask for contributions

The community is there to help you! There are many ways you can reduce your workload by interacting with the community:

• Depending on the project, asking a sample application to reproduce the issue is extremely helpful. A lot of bug reports are closed after the reporter tries to reproduce the issue and, in the process, they find out the bug was caused by something specific to their application. It saves you precious hours from trying to reproduce a bug that you would never find!

• If a user reports a bug, ask the user if he/she feels comfortable to send a pull request with a fix. If you have an idea of where the bug is, send the user links to the relevant part of code, and make it clear you are available in case there are any questions;

• For Elixir, we are experimenting with tagging issues with their “perceived difficulty”, so users who want to contribute to the language can help you solve existing issues. I often list small/medium features we plan to tackle in there and often they are implemented by the community and sent as pull requests;

Find out what works for you and the community

The important thing is to find out what works for you, the other maintainers and the community. For example, while working on Elixir, I was used to close features requests that I could see that would not be part of the language in the next 6 months, even though they were features I liked too! This eventually led to some questions from the community about the approach taken in our issues tracker.

The truth is: if the feature is really useful, you will hear about it many more times! I explained the approach to the community and showed how not having such entries in the issues tracker helps us keep focus on actual bug reports and actionable tasks. Which led everyone to agree with this direction.

Try things and listen to the feedback and hopefully you will find a workflow that works nicely for everyone involved!

Be nice!

Finally, be nice and be polite! Let your contributors know that you appreciate their work as much as they appreciate yours!

What about you? Do you have any tips to share regarding OSS projects maintenance?

The post Tips for keeping your Open Source Software issues tracker tidy first appeared on Plataformatec Blog.

Whenever you try to reset your password or confirm your account, Devise gives you precise information on how to proceed, if the e-mail given is valid, if the token has not expired and so on. This means that, by trying any given e-mail, a third-party person can know if a particular e-mail is registered in that website or not.

While this is not a problem for many applications, some applications would like to keep their user information completely private, even if it means loss of usability on features like account confirmation. For such use cases, Devise supports something called paranoid mode, which has been reported to still be vulnerable to enumeration on sign in.

Releases

Only applications using Devise paranoid mode need to update. New releases have been made for Devise branches 3.2 (3.2.1), 3.1 (3.1.2), 3.0 (3.0.4) and 2.2 (2.2.8).

Users running on those branches and cannot upgrade immediately can fix this issue by applying this patch. Users running on older versions are recommended to upgrade to a supported branch immediately.

Acknowledgements

We want to thank Tim Goddard, from YouDo Ltd for reporting the issue and working with us on a fix.

The post E-mail enumeration in Devise in paranoid mode first appeared on Plataformatec Blog.

Devise 3.1.0.rc runs on both Rails 3.2 and Rails 4.0. There is a TL;DR for upgrading at the end of this post.

Note: We have yanked 3.1.0.rc and released to 3.1.0.rc2 which fixes some regressions. Thanks everyone for trying out the release candidates!

Do not sign the user in after confirmation

In previous Devise versions, the user was automatically signed in after confirmation. This meant that anyone that could access the confirmation e-mail could sign into someone’s account by simply clicking the link.

Automatically signing the user in could also be harmful in the e-mail reconfirmation workflow. Imagine that a user decides to change his e-mail address and, while doing so, he makes a typo on the new e-mail address. An e-mail will be sent to another address which, with the token in hands, would be able to sign in into that account.

If the user corrects the e-mail straight away, no harm will be done. But if not, someone else could sign into that account and the user would not know that it happened.

For this reason, Devise 3.1 no longer signs the user automatically in after confirmation. You can temporarily bring the old behavior back after upgrading by setting the following in your config/initializers/devise.rb:

config.allow_insecure_sign_in_after_confirmation = true

This option will be available only temporarily to aid migration.

Thanks to Andri Möll for reporting this issue.

Do not confirm account after password reset

In previous Devise versions, resetting the password automatically confirmed user accounts. This worked fine in previous Devise versions which confirmed the e-mail just on sign up, so the e-mail both confirmation and password reset tokens would be sent to were guaranteed to be the same. With the addition of reconfirmable, this setup change and Devise will no longer confirm the account after password reset.

Thanks to Andri Möll for reporting this issue and working with us on a fix.

CSRF on sign in

Devise’s sign in page was vulnerable to CSRF attacks when used with the rememberable feature. Note that the CSRF vulnerability is restricted only to the sign in page, allowing an attacker to sign the user in an account controlled by the attacker. This vulnerability does not allow the attacker to access or change a user account in any way.

This issue is fixed on Devise 3.1.0 as well as 3.0.2 and 2.2.6. Users on previous Devise versions can patch their application by simply defining the following in their ApplicationController:

def handle_unverified_request
  super
  Devise.mappings.each_key do |key|
    cookies.delete "remember_#{key}_token"
  end
end

Thanks to Kevin Dew for reporting this issue and working with us on a fix.

Store digested tokens in the database

In previous versions, Devise stored the tokens for confirmation, reset password and unlock directly in the database. This meant that somebody with read access to the database could use such tokens to sign in as someone else by, for example, resetting their password.

In Devise 3.1, we store an encrypted token in the database and the actual token is sent only via e-mail to the user. This means that:

• Devise now requires a config.secret_key configuration. As soon as you boot your application under Devise 3.1, you will get an error with information about how to proceed;
• Every time the user asks a token to be resent, a new token will be generated;
• The Devise mailer now receives one extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use @token, as shown here, instead of getting the token directly from the resource;
• Any previously stored token in the database will no longer work unless you set config.allow_insecure_token_lookup = true in your Devise initializer. We recomend users upgrading to set this option on production only for a couple days, allowing users that just requested a token to get their job done.

Thanks to Stephen Touset for reporting this issue and working with us on a solution.

Token Authenticatable

Jay Feldblum also wrote to us to let us know that our tokens lookup are also vulnerable to timing attacks. Although we haven’t heard of any exploit via timing attacks on database tokens, there is a lot of research happening in this area and some attacks have been successful over the local network. For this reason, we have decided to protect applications using Devise from now on.

By digesting the confirmation, reset password and unlock tokens, as described in the previous section, we automatically protected those tokens from timing attacks.

However, we cannot digest the authentication token provided by TokenAuthenticatable, as they are often part of APIs where the token is used many times. Since the usage of the authenticatable token can vary considerably in between applications, each requiring different safety guarantees, we have decided to remove TokenAuthenticatable from Devise, allowing users to pick the best option. This gist describes two of the available solutions.

Thanks to Jay Feldblum for reporting this issue and working with us on a solution.

TL;DR for upgrading

As soon as you update Devise, you will get a warning asking you to set your config.secret_key. By upgrading Devise, your previous confirmation, reset and unlock tokens in the database will no longer work unless you set the following option to true in your Devise initializer:

config.allow_insecure_token_lookup = true

It is recommended to leave this option on just for a couple days, just to allow recently generated tokens by your application to be consumed by users. TokenAuthenticable has not been affected by those changes, however it has been deprecated and you will have to move to your own token authentication mechanisms.

Furthermore, the Devise mailer now receives an extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use @token, as shown here, instead of getting the token directly from the resource.

With those changes, we hope to provide an even more secure authentication solution for Rails developers, while maintaining the flexibility expected from Devise.

The post Devise 3.1: Now with more secure defaults first appeared on Plataformatec Blog.