CSRF

This is a filter which prevents Cross-Site Request Forgery based on a route or virtual host settings. At it’s simplest, CSRF is an attack that occurs when a malicious third-party exploits a vulnerability that allows them to submit an undesired request on the user’s behalf.

A real-life example is cited in section 1 of Robust Defenses for Cross-Site Request Forgery:

“For example, in late 2007 [42], Gmail had a CSRF vulnerability. When a Gmail user visited a malicious site, the malicious site could generate a request to Gmail that Gmail treated as part of its ongoing session with the victim. In November 2007, a web attacker exploited this CSRF vulnerability to inject an email filter into David Airey’s Gmail account [1].”

There are many ways to mitigate CSRF, some of which have been outlined in the OWASP Prevention Cheat Sheet. This filter employs a stateless mitigation pattern known as origin verification.

This pattern relies on two pieces of information used in determining if a request originated from the same host. * The origin that caused the user agent to issue the request (source origin). * The origin that the request is going to (target origin).

When the filter is evaluating a request, it ensures both pieces of information are present and compares their values. If the source origin is missing or the origins do not match the request is rejected. The exception to this being if the source origin has been added to the policy as valid.

Note

Due to differing functionality between browsers this filter will determine a request’s source origin from the Origin header. If that is not present it will fall back to the host and port value from the requests Referer header.

For more information on CSRF please refer to the pages below.

Configuration

The CSRF filter supports the ability to extend the source origins it will consider valid. The reason it is able to do this while still mitigating cross-site request forgery attempts is because the target origin has already been reached by the time front-envoy is applying the filter. This means that while endpoints may support cross-origin requests they are still protected from malicious third-parties who have not been whitelisted.

It’s important to note that requests should generally originate from the same origin as the target but there are use cases where that may not be possible. For example, if you are hosting a static site on a third-party vendor but need to make requests for tracking purposes.

Warning

Additional origins can be either an exact string, regex pattern, prefix string, or suffix string. It’s advised to be cautious when adding regex, prefix, or suffix origins since an ambiguous origin can pose a security vulnerability.

Runtime

The CSRF filter supports the following RuntimeFractionalPercent settings:

filter_enabled

The % of requests for which the filter is enabled. The default is 100/HUNDRED.

To utilize runtime to enabled/disable the CSRF filter set the runtime_key value of the filter_enabled field.

shadow_enabled

The % of requests for which the filter is enabled in shadow only mode. Default is 0. If present, this will evaluate a request’s Origin and Destination to determine if the request is valid but will not enforce any policies.

To utilize runtime to enabled/disable the CSRF filter’s shadow mode set the runtime_key value of the shadow_enabled field.

To determine if the filter and/or shadow mode are enabled you can check the runtime values via the admin panel at GET /runtime.

Note

If both filter_enabled and shadow_enabled are on, the filter_enabled flag will take precedence.

Statistics

The CSRF filter outputs statistics in the <stat_prefix>.csrf.* namespace.

Name Type Description
missing_source_origin Counter Number of requests that are missing a source origin header.
request_invalid Counter Number of requests whose source and target origins do not match.
request_valid Counter Number of requests whose source and target origins match.