Add strong parameters to the PasswordsController

[hakeem0114]

Problem

The Devise::PasswordsController uses unsanitized resource_params during password reset.

Proposal

• Add a new :reset_password action to the DEFAULT_PERMITTED_ATTRIBUTES

DEFAULT_PERMITTED_ATTRIBUTES = {
      sign_in: [:password, :remember_me],
      sign_up: [:password, :password_confirmation],
      account_update: [:password, :password_confirmation, :current_password]
      reset_password: [:reset_password_token, :password, :password_confirmation]
    }

• Use it in the Devise::PasswordsController.

[timdiggins]

@hakeem0114 I don't agree. The code you reference is

devise/app/controllers/devise_controller.rb

Lines 221 to 223 in fec67f9

	def resource_params
	params.fetch(resource_name, {})
	end

but params.fetch (see https://api.rubyonrails.org/classes/ActionController/Parameters.html#method-i-fetch) still returns a ActionController::Parameters instance (unless the resource name is not present in the params, but in this case it will return an empty hash) so it is still subject to ActionController::Parameters prevention of mass-assignment (like #require but without requiring the resource name), so doesn't AFAICT introduce a security problem needing fixing

[hakeem0114]

@timdiggins Thanks for the comment!
This is a feature enhancement proposal not a bug. I can't seem to add a label on this issue for some reason.
When resource_params is called in the PasswordsController, it returns the entire resource (:user) instead of a sanitized one like the other controllers.

[timdiggins]

@hakeem0114 Ah - ok, if it's a feature request, what benefit does it bring? (the problem statement still implies to me that it's a security issue)

FYI After more looking, I think that in fact the security in devise (from not mass assigning) doesn't really come from strong parameters but from a very similar (but unconnected) route -- see Devise::Models::Authenticatable::ClassMethods# find_or_initialize_with_errors