Skip to main content

Insecure functionality - User management

Need​

Secure user management functionality

Context​

  • Usage of Ruby 2.0+ for developing Ruby applications
  • Usage of Rails framework for building web applications
  • Detection of Vulnerabilities in Node.js Packages
  • Usage of UserMailer for sending email notifications

Description​

Non compliant code​

class VulnerabilityController < ApplicationController
  def assign_manager(email, vulnerability_id)
    vulnerability = Vulnerability.find(vulnerability_id)
    vulnerability.manager_email = email
    vulnerability.save
    send_email(email, vulnerability)
  end

  def send_email(email, vulnerability)
    UserMailer.with(user: email, vulnerability: vulnerability).new_vulnerability_email.deliver_later
  end
end

The above Ruby on Rails code represents a controller for managing vulnerabilities in an application. It has a method assign_manager which assigns a manager to a vulnerability based on their email. This method does not check if the provided email belongs to a registered user in the system, hence it is possible to assign non-users as managers.

The assign_manager method saves the manager's email directly to the vulnerability record and then sends an email to the manager with the vulnerability details. This is done through the send_email method which uses the UserMailer to send an email asynchronously.

This code is insecure because it allows for information disclosure. Vulnerability details can be sent to any email, even if the email does not belong to a registered user. Furthermore, even if a user has been removed from all projects, they can still receive emails with vulnerability details because the system retains their email. This can lead to unauthorized access to sensitive data.

Steps​

  • Implement proper user authentication and authorization mechanisms to ensure that only registered and authorized users can access and manage vulnerabilities.
  • Validate the email address before assigning it as the manager of a vulnerability. Ensure that the email belongs to a registered user in the system.
  • Remove the ability to assign non-users as vulnerability managers.
  • Implement a mechanism to revoke access to vulnerability information for users who have been removed from all projects in an organization.
  • Review and update the email sending functionality to ensure that it only sends emails to registered and authorized users.
  • Consider implementing a notification system that allows users to opt-in or opt-out of receiving vulnerability-related emails.
  • Regularly review and update the user management functionality to address any potential security vulnerabilities.

Compliant code​

class VulnerabilityController < ApplicationController
  before_action :authenticate_user!

  def assign_manager(email, vulnerability_id)
    user = User.find_by_email(email)
    if user.nil?
      flash[:error] = "User with email #{email} does not exist."
      redirect_to :back
    else
      vulnerability = Vulnerability.find(vulnerability_id)
      if vulnerability.nil?
        flash[:error] = "Vulnerability with id #{vulnerability_id} does not exist."
        redirect_to :back
      else
        vulnerability.manager_email = email
        vulnerability.save
        send_email(email, vulnerability)
      end
    end
  end

  def send_email(email, vulnerability)
    user = User.find_by_email(email)
    if user.nil?
      flash[:error] = "User with email #{email} does not exist."
      redirect_to :back
    else
      UserMailer.with(user: user, vulnerability: vulnerability).new_vulnerability_email.deliver_later
    end
  end
end

The updated code now includes a before_action to authenticate the user. This ensures that only registered and logged-in users can access the assign_manager and send_email methods.

In the assign_manager method, we first check if the user with the provided email exists in the system. If the user does not exist, we display an error message and redirect the user back to the previous page. If the user exists, we proceed to find the vulnerability with the provided id. If the vulnerability does not exist, we display an error message and redirect the user back to the previous page. If the vulnerability exists, we assign the user's email as the manager of the vulnerability and save the changes.

In the send_email method, we again check if the user with the provided email exists in the system. If the user does not exist, we display an error message and redirect the user back to the previous page. If the user exists, we send an email to the user with the details of the new vulnerability.

This updated code ensures that only registered and authorized users can manage vulnerabilities and receive vulnerability-related emails. It also provides error handling for cases where the user or vulnerability does not exist.

References​

Last updated on