Skip to main content

Insecure Access Control

Fixing Sensitive Data in URLS​

About Sensitive Data in URLs

What is Sensitive Data in URLs?​

Sensitive data in URLs refers to confidential or personally identifiable information that is included in the web address (URL) of a webpage. This can include information such as usernames, passwords, session IDs, credit card numbers, and other sensitive information that should not be visible or accessible to unauthorized parties.

Sensitive data in URLs can be a security risk because URLs can be intercepted and viewed by third parties, such as internet service providers, proxies, or attackers who are monitoring network traffic. If sensitive data is included in a URL, it can be captured and used by attackers to gain unauthorized access to user accounts, steal sensitive information, or carry out other types of attacks.

Check out this video for a high-level explanation:

What is the impact of Sensitive Data in URLs?​

Sensitive data in URLs can lead to various security threats, such as:

  • Information disclosure: Sensitive data in URLs can be intercepted by attackers, leading to the exposure of confidential or personally identifiable information.
  • Account hijacking: Attackers can use sensitive data in URLs, such as session IDs, to gain unauthorized access to user accounts and perform various malicious activities, such as stealing sensitive information or modifying account settings.
  • Phishing attacks: Attackers can create fake web pages that mimic legitimate sites and include sensitive data in URLs to trick users into revealing their login credentials or other sensitive information.
  • Cross-site scripting (XSS) attacks: Attackers can inject malicious code into URLs that, when executed by a user's browser, can steal sensitive data, such as cookies or session IDs.

Overall, sensitive data in URLs can compromise the confidentiality, integrity, and availability of user data, leading to a range of security threats and risks.

Attackers can obtain information from query strings that can be utilized in attacks against the application and its users.

How to prevent Sensitive Data in URLs?​

To mitigate the risk of sensitive data in URLs, follow security best practices, such as encrypting data using secure protocols like HTTPS, avoiding the use of GET requests for sensitive data, and using session tokens or cookies to manage user sessions instead of embedding session IDs in URLs.

By following these best practices, web applications can help protect sensitive data and ensure the security and privacy of user information.

References​

Taxonomies​

Explanation & Prevention​

Training​

This rule detects the use of insecure URL rewriting methods encodeURL and encodeRedirectURL. This results in the session ID being embedded in the URL where it can be obtained by third parties. If you want to send a redirect, use sendRedirect instead. If you want to encode parameters, leverage URLEncoder.encode when constructing the redirect URL.

Read below on how to fix this issue.

Option A: Use HttpServletResponse.sendRedirect​

Avoid using the methods encodeURL and encodeRedirectURL and use sendRedirect instead.

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

  2. Look for instances where encodeURL or encodeRedirectURL are used.

    private void URLRedirect(HttpServletResponse resp, String url) {
        if (url != null) {
            resp.encodeRedirectURL(url);
        }
    }

  3. Replace it with HttpServletResponse.sendRedirect

    private void URLRedirect(HttpServletResponse resp, String url) {
        if (url != null) {
            resp.sendRedirect(url);
        }
    }

  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​

The following issues are detected by GuardRails:

  • Disabled CSRF: Disabling Spring Security's CSRF protection is unsafe for standard web applications. A valid use case for disabling this protection would be a service exposing state-changing operations that is guaranteed to be used only by non-browser clients.

  • Unrestricted Spring RequestMapping: Methods annotated with RequestMapping are by default mapped to all the HTTP request methods. However, Spring Security's CSRF protection is not enabled by default for the HTTP request methods GET, HEAD, TRACE, and OPTIONS (as this could cause the tokens to be leaked). Therefore, state-changing methods annotated with RequestMapping and not narrowing the mapping to the HTTP request methods POST, PUT, DELETE, or PATCH are vulnerable to CSRF attacks.

Option A: Configure CSRF securely​

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

  2. Identify the following patterns:

    //Disabled CSRF
    @EnableWebSecurity
    public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
      @Override
      protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable();
      }
    }

    or:

    @Controller
    public class UnsafeController {
      @RequestMapping("/path")
      public void writeData() {
          // State-changing operations performed within this method.
      }
    }

  3. Otherwise, use the following pattern instead:

    @Controller
    public class SafeController {
      /**
      * For methods without side-effects use @GetMapping.
      */
      @GetMapping("/path")
      public String readData() {
        // No state-changing operations performed within this method.
        return "";
      }
      /**
      * For state-changing methods use either @PostMapping, @PutMapping, @DeleteMapping, or @PatchMapping.
      */
      @PostMapping("/path")
      public void writeData() {
        // State-changing operations performed within this method.
      }
    }

  4. Test it and ensure the functionality works as expected

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier