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:
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.
- Go through the issues that GuardRails identified in the PR.
- Locate the router with the following pattern:
defmodule TestRouter do
pipeline :browser do
plug(:accepts, ["html"])
plug(:fetch_session)
plug(:fetch_flash)
end
end
- 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
- Test it
- 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
check_origin
is enabled
Option A: Ensure - Go through the issues that GuardRails identified in the PR.
- Locate the endpoint with the following pattern:
socket(
"/socket",
PhoenixInternalsWeb.UserSocket,
websocket: [check_origin: false],
longpoll: false
)
- And either remove the
check_origin
flag, or set it totrue
socket("/socket", PhoenixInternalsWeb.UserSocket,
websocket: [check_origin: true],
longpoll: false
)
- Test it
- 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
- Go through the issues that GuardRails identified in the PR.
- Locate the endpoint with the following pattern:
pipeline :browser do
plug(:accepts, ["html"])
plug(:protect_from_forgery)
end
- And add the
put_secure_browser_headers
plug
pipeline :browser do
plug(:accepts, ["html"])
plug(:protect_from_forgery)
plug(:put_secure_browser_headers)
end
- Test it by checking your URL at SecurityHeaders.io
- 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
- Go through the issues that GuardRails identified in the PR.
- Locate the endpoint with the following pattern:
force_ssl: [hsts: false]
- And add the
put_secure_browser_headers
plug
force_ssl: [hsts: true]
- Test it by checking your URL at SecurityHeaders.io
- 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
- Go through the issues that GuardRails identified in the PR.
- Locate the router with the following pattern:
pipeline :browser do
plug(:accepts, ["html"])
plug(:put_secure_browser_headers)
end
- 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
- Test it by checking your URL at SecurityHeaders.io
- Ship it 🚢 and relax 🌴