Prevention of unauthorized access to client information on the GLIA application
class UsersController < ApplicationController
before_action :set_user, only: [:show, :edit, :update, :destroy]
# GET /users/1
def show
end
private
# Use callbacks to share common setup or constraints between actions.
def set_user
@user = User.find(params[:id])
end
end
In the above code, any logged-in advisor can access the details of any user just by knowing their id and hitting the show route. The
set_user
method is fetching the user based on the id passed in the request parameters without any authorization checks. This is a major security flaw as it allows unauthorized access to sensitive user data.
The
show
action in the
UsersController
is responsible for displaying the details of a user. The user is fetched by the
set_user
method, which is executed before the
show
action due to the
before_action
callback at the top of the controller. The
set_user
method fetches the user from the database based on the id provided in the request parameters.
The vulnerability lies in the fact that there are no checks to ensure that the logged-in advisor is authorized to view the details of the user they are trying to access. This means that an advisor can simply change the id in the URL to view the details of any user, which is a breach of privacy and a major security concern.
class UsersController < ApplicationController
before_action :set_user, only: [:show, :edit, :update, :destroy]
before_action :authenticate_user!
before_action :authorize_user!, only: [:show]
# GET /users/1
def show
end
private
# Use callbacks to share common setup or constraints between actions.
def set_user
@user = User.find(params[:id])
end
def authenticate_user!
redirect_to new_session_path unless current_user
end
def authorize_user!
redirect_to root_path unless current_user == @user || current_user.admin?
end
end
The updated code includes two new before_action filters:
authenticate_user!
and
authorize_user!
.
The
authenticate_user!
method is used to ensure that a user is logged in before they can access any of the actions in the UsersController. If a user is not logged in, they will be redirected to the login page.
The
authorize_user!
method is used to ensure that the logged-in user has the necessary permissions to access the show action. In this case, a user can only access the show action if they are trying to view their own profile or if they are an admin. If a user tries to access a profile that they do not have permission to view, they will be redirected to the root path.
These changes ensure that only authorized users can access the show action in the UsersController, preventing advisors from being able to access client information.