Skip to main content

Insecure Configuration

This vulnerability category covers the following issues:

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:

Security Misconfiguration

More information:

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:

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:

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:

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:

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:

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 ๐ŸŒด

More information:โ€‹