Need

Protection of sensitive user information from being leaked through browser side-channels

Context

• Usage of Ruby 2.7 for Ruby programming language development
• Usage of Rails framework for building web applications
• Usage of ActiveRecord for Object-Relational Mapping (ORM) in database operations

Description

Non compliant code

        class UsersController < ApplicationController
  def show
    @user = User.find(params[:id])
  end
end
        
        

This is a simple example of a Ruby on Rails controller action that fetches a user by their ID from the database. The ID is taken directly from the request parameters, which are easily manipulated by the client.

Although this code does not directly leak any information, it can be exploited in combination with a Cross-Site Leak (XS-Leak) vulnerability on the client-side. An attacker could potentially use this to gather sensitive information about users.

For example, an attacker could use a timing attack to determine whether or not a user exists in the database. They could repeatedly request this endpoint with different IDs, and measure how long the server takes to respond. If the server takes noticeably longer to respond for certain IDs, it could indicate that those IDs correspond to real users.

This leak of information might seem minor, but in combination with other vulnerabilities or pieces of leaked information, it could contribute to a larger security breach.

Steps

• Implement server-side filtering and validation to ensure that only authorized users can access sensitive information.
• Avoid exposing sensitive information in the response body or headers.
• Implement proper access controls and authentication mechanisms to prevent unauthorized access to user data.
• Regularly update and patch the Ruby on Rails framework to ensure that any security vulnerabilities are addressed.
• Implement secure coding practices to prevent other types of vulnerabilities that could lead to information leakage.

Compliant code

        class UsersController < ApplicationController
  before_action :authenticate_user!
  before_action :correct_user, only: [:show]

  def show
    @user = User.find(params[:id])
  end

  private

  def correct_user
    @user = User.find(params[:id])
    redirect_to(root_url) unless current_user?(@user)
  end

  def current_user?(user)
    user == current_user
  end
end
        
        

The updated code now includes two before_action filters at the top of the UsersController class. These filters are methods that get run before certain controller actions, in this case, the show action.

The authenticate_user! method is a built-in Devise helper method that ensures a user is logged in before they can access the action. If a user is not logged in, they will be redirected to the login page.

The correct_user method is a new method that we've defined in the private section of the controller. This method finds the user based on the id parameter and checks if the current logged-in user is the same as the user found. If they are not the same, the method redirects the user to the root URL. This ensures that users can only view their own data, preventing unauthorized access to sensitive information.

The current_user? method is a helper method that checks if the given user is the same as the currently logged in user.

By implementing these changes, we can ensure that only authorized users can access sensitive information, thereby mitigating the risk of XS-Leaks.

References

• 116. XS-Leaks