application_security/csrf

13 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

CSRF token field default name and customization

By default the CSRF token in Symfony Form component is added as a hidden field called '_token', but this can be customized on a form-by-form basis using configuration options: 'csrf_protection' (true/false to enable/disable), 'csrf_field_name' (custom field name), and 'csrf_token_id' (arbitrary string used to generate the token).

CSRF protection in Symfony Form component

Symfony Form component automatically includes CSRF tokens in forms and validates them automatically, providing built-in protection against CSRF attacks without requiring manual intervention.

Manual CSRF token generation and validation without Symfony Forms

To generate and validate CSRF tokens without using Symfony Forms, install the 'symfony/security-csrf' component. Enable/disable CSRF protection in config/packages/framework.yaml under 'framework.csrf_protection: ~'. Generate tokens using the csrf_token() Twig function and validate them in controllers using the isCsrfTokenValid() function.

CSRF token Twig function syntax

The csrf_token() Twig function generates CSRF tokens. Syntax: {{ csrf_token('token-id') }}. The 'token-id' is an arbitrary string that identifies the token purpose, for example 'delete-post'.

WebSocket Origin header validation CSWSH defense

Validate the Origin header on every WebSocket handshake using an explicit allowlist of trusted origins. Browsers include this header and malicious JavaScript cannot override it. Use an allowlist, not a denylist. Avoid wildcards or substring matching which are error-prone. Example: const wss = new WebSocket.Server({ verifyClient: (info) => { const allowedOrigins = ['https://app.example.com']; if (!allowedOrigins.includes(info.origin)) { return false; } return true; } });

Cross-Site WebSocket Hijacking CSWSH attack scenario

CSWSH attack sequence: User logs into your application (session cookie established). User later visits a malicious website. Malicious site opens WebSocket to your application, browser sends cookies automatically. Server accepts the connection and attacker gets live, authenticated WebSocket access.

Gitpod CSWSH CVE 2023 account takeover insufficient origin validation

Gitpod had a CSWSH vulnerability in 2023 (GHSA-f53g-frr2-jhpf) where insufficient origin validation allowed full account takeover via hijacked WebSocket connections.

WebSocket CSRF token protection additional CSWSH defense

For applications already using CSRF protection, include CSRF tokens in WebSocket handshakes as an additional CSWSH defense.

SameSite cookie attribute values and behavior

The SameSite attribute controls whether a browser includes cookies in cross-site requests. None: the cookie will be attached to requests from another site but must be sent over HTTPS. Lax: the cookie will be appended to requests from another page if the request method is GET and the request is made to top-level navigation (changing the browser's address bar). Strict: the cookie will never be sent from another site. Chromium-based browsers treat cookies without an explicit SameSite attribute as Lax by default.

Same-origin determination: protocol, port, and host

Two URLs are considered same-origin if their protocol, port, and host are identical. Any origin can send a request to another origin, but due to Same-origin Policy, the requesting origin cannot read the response directly. Same-origin Policy may be relaxed by Cross-Origin Resource Sharing (CORS).

eTLD+1 definition for SameSite context

In the SameSite attribute context, a site is the combination of the TLD (top-level domain) and the domain name before it, also called eTLD+1. This uses effective TLDs rather than simple TLDs because some domains like .github.io or .eu.org are not atomic enough. The effective TLD list is maintained at https://publicsuffix.org/list/public_suffix_list.dat. Sites with the same eTLD+1 are considered SameSite, regardless of scheme or subdomain differences.

Subresource protection with unique tokens

Protect sensitive endpoints using special unique tokens in the request, for example: /api/users/1234?token=be9••••••03. Tokens should be long, unique, and the backend must correctly validate the token passed in the request. This defense is effective but generates significant overhead in proper implementation.

postMessage targetOrigin specification for security

When using postMessage to exchange information between different origins despite the Same-Origin Policy, always specify the exact targetOrigin parameter instead of using the wildcard '*'. Passing '*' as targetOrigin causes any origin to receive the message. Specifying a strict targetOrigin like 'https://sub.example.com' prevents attackers from receiving messages even if they obtain a window reference.

Give your agent this brain