Skip to main content

Insecure Access Control

Fixing Insecure Access Control​

About Insecure Access Control

What is improper access control?​

Improper access control is a vulnerability that occurs when a system does not properly restrict or enforce access to resources, such as files, directories, network resources, or application functions.

Examples of improper access control vulnerabilities include:

  • Weak access controls: When access controls are weak or easily bypassed, attackers can gain access to sensitive resources or data by exploiting security weaknesses.
  • Insufficient authorization checks: When authorization checks are insufficient, it can allow unauthorized users to access sensitive data or resources, or to perform actions that they are not authorized to do.
  • Overly permissive access: When access controls are overly permissive, they can allow users to access resources or data that they do not need, increasing the risk of data breaches or other security incidents.

Check out these videos for a high-level explanation:

  • Missing function level access control

  • Missing object level access control

What is the impact of improper access control?​

Improper access control can lead to various security threats, such as:

  • Data breaches: Improper access control can allow attackers to access sensitive data, leading to data breaches, data loss, or unauthorized access to confidential information.
  • Unauthorized access to resources: Attackers can exploit improper access control to gain unauthorized access to resources, such as servers, databases, and applications.
  • Account takeover: Attackers can use improper access control to take over user accounts and gain access to sensitive data or resources.

How to prevent improper access control?​

Here are some measures that can help ensure proper access control:

  • Strong access controls: Implement strong access controls that restrict access to sensitive resources or data based on user roles and permissions.
  • Proper user authentication and authorization: Implement proper user authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
  • Input validation and sanitization: Validate and sanitize user input before using it to access internal objects or data. Use regular expressions or input filters to remove or encode any special characters that could be used to access sensitive data or resources.
  • Least privilege: Use the principle of least privilege to restrict access to resources to only what is necessary for each user role. This can help prevent attackers from gaining access to resources that they do not need to access.
  • Regular security audits: Regularly audit your system for security vulnerabilities, including improper access control vulnerabilities. Use automated tools and manual testing to identify potential issues and fix them before they can be exploited.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Use ESAPI Access Control​

In APEX it is important to check for permissions before any SOQL/SOSL/DML operation, which includes classes declared without explicit sharing mode if DML methods are used. Since Apex runs in system mode, not having proper permissions checks results in escalation of privilege and may produce runtime errors. It is considered a security best practice to always handle such scenarios.

Rule-specific resources:

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Identify patterns like below and ensure that the ACL is not NULL.

    public class Foo {
      public Contact foo(String status, String ID) {
          Contact c = [SELECT Status__c FROM Contact WHERE Id=:ID];

          // Make sure we can update the database before even trying
          if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()) {
              return null;
          }

          c.Status__c = status;
          update c;
          return c;
      }
    }

    or:

    public without sharing class Foo {
        // DML operation here
    }

  3. Ensure that the ESAPI.accessController() methods are added to ensure proper access control.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing Open Redirects​

About Open Redirects

What are open redirects?​

Open redirect is a web application vulnerability that occurs when an application uses unvalidated user input as part of a redirect URL.

An attacker can exploit this vulnerability by manipulating the input to redirect a victim to a malicious site. The impact of this vulnerability can range from phishing attacks to theft of sensitive information.

Check out this video for a high-level explanation:

What is the impact of open redirects?​

An open redirect vulnerability can allow an attacker to:

  • Conduct phishing attacks: An attacker can trick a victim into clicking a link that appears to be legitimate but actually redirects them to a malicious website where their sensitive information can be compromised.
  • Steal sensitive information: An attacker can craft a URL that appears to be legitimate but redirects to a site that steals the victim's sensitive information, such as login credentials or credit card information.
  • Distribute malware: An attacker can use an open redirect to send victims to a site that distributes malware, allowing them to gain control of the victim's device.

How to prevent open redirects?​

To prevent improper open redirect vulnerabilities, it is important to implement secure coding practices, including:

  • Validate redirect URLs: Ensure that all redirect URLs are validated and verified before being used in the application. This can include ensuring that the redirect URL is within the same domain as the current page or using an allow list of permitted domains.
  • Avoid using untrusted input: Avoid using untrusted user input as part of a redirect URL. Use a standard URL-building function instead, which allows you to control the parameters used in the redirect URL.
  • Implement security headers: Implement security headers such as Content-Security-Policy (CSP) and X-Frame-Options to help prevent open redirect attacks.
  • Use secure coding practices: Use secure coding practices to prevent open redirect vulnerabilities. This includes input validation, output encoding, and regular security audits.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Avoid dynamic values in redirects​

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Look for patterns like this:

    public without sharing class Foo {
      String unsafeLocation = ApexPage.getCurrentPage().getParameters.get('url_param');
      PageReference page() {
        return new PageReference(unsafeLocation);
      }
    }

  3. Ensure that the location is either static, or the user input is sanitized.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing Cross-Site Request Forgery​

About Cross-Site Request Forgery (CSRF)

What is Cross-Site Request Forgery?​

Cross-site request forgery (CSRF or XSRF) is a type of web application vulnerability that allows an attacker to exploit the trust relationship between a user's web browser and a web application. The vulnerability occurs when a web application doesn't adequately verify that a request comes from an authorized user, and it can allow an attacker to force an unsuspecting user to perform actions on the application without their knowledge or consent.

In a CSRF attack, an attacker will create a malicious website or email that contains a link or form that automatically sends a request to the vulnerable web application. If the victim clicks on the link or submits the form, the request will be sent to the web application, and the application will assume that it was initiated by the legitimate user.

Check out this video for a high-level explanation:

What is the impact of Cross-Site Request Forgery?​

Some potential impacts of CSRF attacks are:

  • Unauthorized actions: An attacker can use a CSRF attack to force a user to perform unauthorized actions on the vulnerable web application, such as changing their password, making unauthorized purchases, or deleting or modifying data.
  • Data breaches: An attacker can use a CSRF attack to override sensitive information from the vulnerable web application, such as login credentials.
  • Financial loss: An attacker can use a CSRF attack to force a user to make unauthorized financial transactions, resulting in financial loss for the victim.
  • Reputation damage: A successful attack exploiting a CSRF vulnerability can lead to loss of customer trust and reputational damage for the organization.
  • Regulatory violations: A successful attack exploiting a CSRF vulnerability can lead to violations of regulatory requirements, such as data protection laws.

How to prevent Cross-Site Request Forgery?​

To prevent cross-site request forgery (CSRF) attacks, web applications can implement the following measures:

  • Implement CSRF tokens: Use CSRF tokens to ensure that requests are made by legitimate users and not by attackers. The token is a unique value that is generated for each user session, and it is included in each form or link request. The server-side application checks that the token matches the user's session, and if not, it rejects the request.
  • Use HTTP Referer header validation: Validate the HTTP Referer header to ensure that requests are coming from the expected source. This can help prevent attackers from spoofing the source of a request.
  • Use anti-CSRF frameworks: Use anti-CSRF frameworks or libraries that provide built-in protection against CSRF attacks, such as Django's CSRF protection, Spring Security's CSRF protection, or the OWASP CSRFGuard library.
  • Use SameSite cookies: Use SameSite cookies to prevent CSRF attacks that leverage session hijacking through cross-site scripting (XSS) vulnerabilities.
  • Limit the use of HTTP methods: Limit the use of sensitive HTTP methods (e.g. PUT, DELETE) to authenticated and authorized users only.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Avoid DML operations in initializers​

Having DML operations in Apex class constructor or initializers can have unexpected side effects: By just accessing a page, the DML statements would be executed and the database would be modified. Just querying the database is permitted.

Salesforce Apex already protects against this scenario and raises a runtime exception.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Locate the code with the following pattern:

    public class Foo {
      // initializer
      {
        insert data;
      }

      // static initializer
      static {
        insert data;
      }

      // constructor
      public Foo() {
        insert data;
      }
    }

  3. And ensure that these operations are moved to a secure place with proper access control.

  4. Test it

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier