Insecure Configuration

This vulnerability category covers the following issues:

• Cross-Site Request Forgery
• Cross-site WebSocket Hijacking
• Security Headers
• HTTP Strict Transport Security
• Content Security Policy

Why is this important?

Elixir mostly adheres to secure defaults, but there are ways to introduce configuration issues.

Check out this video for a high-level explanation:

More information:

• OWASP Top 10 - A6 Security Misconfiguration

Cross-Site Request Forgery

In a Cross-Site Request Forgery (CSRF) attack, an untrusted application can cause a user's browser to submit requests or perform actions on the user's behalf.

References:

• CSRF Description

Fixing Cross-Site Request Forgery

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.
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.

Cross-Site WebSocket Hijacking

Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) involves a cross-site request forgery (CSRF) vulnerability on a WebSocket handshake. It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.

Websocket connections are not bound by the same-origin policy. Connections that do not validate the origin may leak information to an attacker.

References:

• Cross-Site WebSocket Hijacking
• Cross-Site WebSocket Hijacking - Ref 2

Fixing Cross-Site WebSocket Hijacking

Option A: Ensure check_origin is enabled

1. Go through the issues that GuardRails identified in the PR.
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 🌴

Security Headers

HTTP security headers provide yet another layer of security by helping to prevent certain attacks and security vulnerabilities. These are simple to implement and have a range of benefits to protect your users.

By default, Phoenix HTTP responses contain a number of secure HTTP headers that attempt to prevent XSS, click-jacking, and content-sniffing attacks.

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

References:

• HTTP Security Headers

Fixing Security Headers

Option A: Add the put_secure_browser_headers plug

1. Go through the issues that GuardRails identified in the PR.
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 🌴

HTTP Strict Transport Security

The HTTP Strict Transport Security (HSTS) header is another HTTP Security Header that helps defend against man-in-the-middle attacks by preventing unencrypted connections.

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

References:

• HTTP Strict Transpoprt Security
• PLug.SSL Docs

Fixing HTTP Strict Transport Security

Option A: Set hsts to true

1. Go through the issues that GuardRails identified in the PR.
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 🌴

Content Security Policy

The Content Security Policy (CSP) header is another HTTP Security Header helps defend against including Cross Site Scripting (XSS) and data injection attacks.

References:

• Content Security Policy
• ontent Security Policy - An introduction

Fixing Content Security Policy

Option A: Configure the content-security-policy

1. Go through the issues that GuardRails identified in the PR.
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

@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 🌴