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.

• Versions affected: >= 2.0.0
• Not affected: < 2.0.0
• Fixed versions: 3.1.0, 3.0.3, 2.1.2

Impact

When Simple Form renders an error message it marks the text as being HTML safe, even though it may contain HTML tags. In applications where the error message can be provided by the users, malicious values can be provided and Simple Form will mark them as safe.

Changes at the behavior

To fix this vulnerability error messages are now always escaped. If users need to mark them as safe they will need to use explicitly the :error option:

f.input :name, error: raw("My <b>error</b>")

Releases

The 3.1.0, 3.0.3 and 2.1.2 releases are available at the regular locations.

Workarounds

There are no feasible workarounds for this issue. We recommend all users to upgrade as soon as possible.

Patches

To aid users who aren’t able to upgrade immediately we have provided patches. They are in git-am format and consist of a single changeset.

• Patch for 3.0 series
• Patch for 2.1 series

Credits

Thanks to Jake Goulding, from WhiteHat Security and Nicholas Rutherford from Medify Ltd. for reporting the issue and working with us in a fix.

The post XSS vulnerability on Simple Form first appeared on Plataformatec Blog.

Versions affected: >= 1.1.1
Not affected: < 1.1.1
Fixed versions: 3.0.1, 2.1.1

Impact

When Simple Form creates a label, hint or error message it marks the text as being HTML safe, even though it may contain HTML tags. In applications where the text of these helpers can be provided by the users, malicious values can be provided and Simple Form will mark it as safe.

Releases

The 3.0.1 and 2.1.1 releases are available at the normal locations.

Workarounds

If you are unable to upgrade, you can change your code to escape the input before sending to Simple Form

f.input :name, label: html_escape(params[:label])

Patches

To aid users who aren’t able to upgrade immediately we have provided patches. They are in git-am format and consist of a single changeset.

• 3-0-xss-fix.patch – Patch for 3.0 series
• 2-1-xss-fix.patch – Patch for 2.1 series

Credits

Thank you to Paul McMahon from Doorkeeper for reporting the issue and working with us in a fix.

The post XSS vulnerability on Simple Form 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.

The attack can only be exploited if the attacker can set the target session, either by subdomain cookies (similar to described here) or by fixation over the same Wi-Fi network. If the user knows the CSRF token, cross-site forgery requests can be made. More information can be found here.

Note Devise is not vulnerable to session fixation attacks (i.e. the user cannot steal another user session by fixating the session id).

Releases

Devise 3.0.1 and 2.2.5 have been released with fixes for the attack.

If you can’t upgrade, you must protect your Devise application by adding the next three lines to a Rails initializer:

Warden::Manager.after_authentication do |record, warden, options|
  warden.request.session.try(:delete, :_csrf_token)
end

Notice the code above and the updated Devise versions will clean up the CSRF Token after any authentication (sign in, sign up, reset password, etc). So if you are using AJAX for such features, you will need to fetch a new CSRF token from the server.

Acknowledgements

We want to thank Egor Homakov for reporting the issue and working with us on a fix.

The post CSRF token fixation attacks in Devise first appeared on Plataformatec Blog.