Insecure Configuration

This vulnerability category covers the following issues:

• Cross-Site Request Forgery
• Cross-site WebSocket Hijacking
• Security Headers

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

• OWASP Top 10 - A01 Broken Access Control
• CWE-352: Cross-Site Request Forgery (CSRF)

Explanation & Prevention

• OWASP: Cross-Site Request Forgery (CSRF)
• OWASP: Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
• OWASP: Testing for Cross-Site Request Forgery (CSRF)
• OWASP: CSRFGuard
• Portswigger - CSRF

Related CVEs

• CVE Details: CWE-352

Training

• Secure Code Warrior: Cross-Site Request Forgery (CSRF)

Option A: Add the protect_from_forgery plug

A CSRF can occur when a pipeline fetches a session but does not implement the :protect_from_forgery plug.

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

2. Locate the router with the following pattern:

   defmodule TestRouter do
     pipeline :browser do
       plug(:accepts, ["html"])
       plug(:fetch_session)
       plug(:fetch_flash)
     end
   end

3. And add the :protect_from_forgery plug

   defmodule TestRouter do
     pipeline :browser do
       plug(:accepts, ["html"])
       plug(:protect_from_forgery)
       plug(:fetch_session)
       plug(:fetch_flash)
     end
   end

4. Test it

5. Ship it 🚢 and relax 🌴

Option B: Avoid mixing GET routes with state-changing routes

A CSRF can occur when state-changing routes share an action with GET-based routes. For example:

get "/users", UserController, :new
post "/users", UserController, :new

In this instance, it may be possible to trigger the POST functionality with a GET request and query parameters.

Ensure that all state-changing routes don't have GET-based routes with the same names.

Fixing Cross-Site WebSocket Hijacking

About Cross-Site WebSocket Hijacking (CSWSH)

What is Cross-Site WebSocket Hijacking?

Cross-Site WebSocket Hijacking (CSWSH) is a type of security vulnerability that occurs when a WebSocket connection is established between a user's browser and a remote server. In this type of attack, an attacker can hijack a WebSocket connection and send arbitrary data to the server, potentially leading to unauthorized actions or data theft.

The attack works by tricking the user's browser into establishing a WebSocket connection with a malicious website, which then sends data to the server on behalf of the user. This can be used to bypass authentication mechanisms and perform actions on the user's behalf, such as updating their profile or making unauthorized purchases.

What is the impact of Cross-Site WebSocket Hijacking?

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 WebSocket Hijacking?

CSWSH attacks can be difficult to detect and prevent, as the WebSocket connection is established using JavaScript code on the client-side, and the data is transmitted over a secure, encrypted channel.

However, there are best practices that can help to prevent CSWSH attacks:

• Validate the origin of WebSocket connections: Verify that the WebSocket connection is being established from a trusted origin. This can be done by checking the Origin header in the WebSocket handshake request.
• Use cookies with the SameSite attribute: Use cookies with the SameSite attribute set to strict or lax. This can help prevent cross-site request forgery (CSRF) attacks, which can be used to initiate a CSWSH attack.
• Use authentication and authorization: Implement strong authentication and authorization mechanisms to prevent unauthorized access to sensitive data or actions.
• Use secure WebSocket connections: Use secure WebSocket connections (wss://) to encrypt the data transmitted between the client and server, and prevent eavesdropping or tampering.

References

Taxonomies

• CWE-1385: Missing Origin Validation in WebSockets

Explanation & Prevention

• OWASP: Testing WebSockets
• PortSwigger: Cross-site WebSocket hijacking

By default, Phoenix checks the origin of requests when the origin header is present. The check_origin option is true by default but can be disabled.

Solution-specific references:

• Phoenix Docs - Socket
• Phoenix Docs - Socket Configuration
• Phoenix Docs - Endpoint Configuration

Option A: Ensure check_origin is enabled

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

2. Locate the endpoint with the following pattern:

   socket(
     "/socket",
     PhoenixInternalsWeb.UserSocket,
     websocket: [check_origin: false],
     longpoll: false
   )

3. And either remove the check_origin flag, or set it to true

   socket("/socket", PhoenixInternalsWeb.UserSocket,
     websocket: [check_origin: true],
     longpoll: false
   )

4. Test it

5. Ship it 🚢 and relax 🌴

Fixing Security Headers

About HTTP Security Headers

What are insecure HTTP security headers?

HTTP security headers are a set of headers that can be sent by a web server to a user's web browser to help protect against various types of attacks, such as cross-site scripting (XSS), clickjacking, and cross-site request forgery (CSRF).

These headers provide additional security controls that can help to prevent attackers from exploiting vulnerabilities in web applications.

However, if these security headers are not configured correctly, they can be vulnerable to attacks that compromise the security of a website and its users. One common vulnerability is the use of insecure HTTP security headers. Insecure HTTP security headers are settings that can be configured for a security header to specify how the header should be transmitted and stored.

Some common insecure HTTP security headers include:

• "X-Frame-Options" header: This header is used to prevent clickjacking attacks by indicating whether a page can be displayed in an iframe. If the header is not set or is set incorrectly, a page can be vulnerable to clickjacking attacks.
• "Content-Security-Policy" header: This header is used to prevent XSS attacks by specifying which sources of content are allowed to be loaded by a web page. If the header is not set or is set incorrectly, a page can be vulnerable to XSS attacks.
• "X-XSS-Protection" header: This header is used to enable the browser's built-in XSS protection mechanisms. If the header is not set or is set incorrectly, a website can be vulnerable to XSS attacks.
• "Strict-Transport-Security" header: This header is used to ensure that a website is only accessed over HTTPS connections. If the header is not set or is set incorrectly, a website can be vulnerable to man-in-the-middle attacks.
• "Cross-Origin Resource Sharing (CORS)" headers: This header is used to protect against cross-site request forgery (CSRF) and other types of attacks. It specifies which origins, HTTP methods, and credentials are allowed to be accessed.

Check out this video for a high-level explanation:

What is the impact of insecure HTTP security headers?

Some of the potential consequences of using insecure HTTP security headers are:

• Increased risk of cross-site scripting (XSS) attacks: If the "Content-Security-Policy", or "X-XSS-Protection" header is not set or is set incorrectly, a website can be vulnerable to XSS attacks. This can allow attackers to inject malicious code into a website and steal sensitive information, such as login credentials or personal data.
• Increased risk of clickjacking attacks: If the "X-Frame-Options" header is not set or is set incorrectly, a website can be vulnerable to clickjacking attacks. This can allow attackers to trick users into performing actions that they did not intend to perform, such as clicking on a button that executes a malicious action.
• Increased risk of cross-site request forgery (CSRF) attacks: If the "Access-Control-Allow-Origin" header is not set or is set incorrectly, a website can be vulnerable to CSRF attacks. This can allow attackers to trick users into unknowingly performing actions on the website that they did not intend to perform.
• Increased risk of data breaches: If HTTP security headers are not configured correctly, a website can be vulnerable to data breaches. This can allow attackers to steal sensitive information, such as login credentials or personal data, and use it for malicious purposes.

How to prevent insecure HTTP security headers?

Some of the best practices to prevent insecure HTTP security headers are:

• Set the appropriate values for HTTP security headers: Each HTTP security header has a set of valid values that can be used to configure it. Ensure that the appropriate values are set for each header to provide the desired level of protection against attacks.
• Regularly review and update HTTP security header settings: Regularly review and update HTTP security header settings to ensure that they are up-to-date with the latest best practices and security recommendations.
• Use tools to validate HTTP security header settings: Use tools, such as the Mozilla Observatory, to validate the configuration of HTTP security headers and ensure that they are set correctly. These tools can also provide recommendations for improving the security of a website.
• Use a content delivery network (CDN) with built-in security features: Some CDNs offer built-in security features, such as the automatic configuration of HTTP security headers. Consider using a CDN with these features to simplify the configuration and management of HTTP security headers.

References

Taxonomies

• CWE-693: Protection Mechanism Failure

Explanation & Prevention

• OWASP: HTTP Security Response Headers Cheat Sheet
• OWASP: Secure Headers Project

Related CVEs

• CVE Details: CWE-693

Training

• Secure Code Warrior: Security Misconfiguration - Disabled Security Features

By default, Phoenix HTTP responses contain secure HTTP headers that attempt to prevent XSS, click-jacking, and content-sniffing attacks. However, the secure defaults can be disabled, and some directives, such as CSP, need to be configured.

Option A: Add the put_secure_browser_headers plug

In Phoenix applications, an issue occurs if a pipeline accepts "html" requests, but does not implement the :put_secure_browser_headers plug.

Solution-specific references:

• Phoenix Docs - Secure Browser Headers

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

2. Locate the endpoint with the following pattern:

   pipeline :browser do
     plug(:accepts, ["html"])
     plug(:protect_from_forgery)
   end

3. And add the put_secure_browser_headers plug

   pipeline :browser do
     plug(:accepts, ["html"])
     plug(:protect_from_forgery)
     plug(:put_secure_browser_headers)
   end

4. Test it by checking your URL at SecurityHeaders.io

5. Ship it 🚢 and relax 🌴

Option B: Set HSTS to true

In Phoenix applications, an issue occurs if force_ssl is enabled and HSTS is set to false.

Solution-specific references:

• PLug.SSL Docs

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

2. Locate the endpoint with the following pattern:

   force_ssl: [hsts: false]

3. And add the put_secure_browser_headers plug

   force_ssl: [hsts: true]

4. Test it by checking your URL at SecurityHeaders.io

5. Ship it 🚢 and relax 🌴

Option C: Configure the Content-Security-Policy

In Phoenix applications, even though :put_secure_browser_headers is configured, the CSP is not set.

Solution-specific references:

• CSP in Phoenix

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

2. Locate the router with the following pattern:

   pipeline :browser do
     plug(:accepts, ["html"])
     plug(:put_secure_browser_headers)
   end

3. And add the put_secure_browser_headers plug

   # This has to be adjusted to your application use-case
   @csp %{"content-security-policy" => "default-src 'self'"}
   pipeline :browser do
     plug(:accepts, ["html"])
     plug(:put_secure_browser_headers, @csp)
   end

4. Test it by checking your URL at SecurityHeaders.io

5. Ship it 🚢 and relax 🌴