http filter: add CSRF filter

[dschaller]

Signed-off-by: Derek Schaller dschaller@lyft.com

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md

Description: Add a Cross-Site Request Forgery filter
Risk Level: Low
Testing: Change includes unit and integration tests and I manually tested the filter as well.
Docs Changes: Included
Release Notes: Included
Fixes #245

Cross-Site Request Forgery (CSRF) HTTP Filter

CSRF (also known as XSRF, Sea Surf, and Session Riding) is an attack that occurs when a malicious third-party exploits a vulnerability (generally through social engineering) that allows them to submit a malicious request on the user’s behalf. The request relies on the victim having a valid session on the destination site and utilizes this to assume the identity and permissions of the user.

Possible Mitigation Patterns

There are a few different popular mitigation patterns that exist and some of those are either entirely stateful or have a stateful option. For purposes of this feature I am going to ignore the stateful patterns and focus on the stateless ones. This is because we don’t want to introduce state management into Envoy if there is another option which is just as secure.

A common pattern to mitigate CSRF attacks is utilizing tokens that help discern requests made by the user versus requests made by a malicious third-party. This approach is the most popular and is the recommended approach by OWASP. There are three approaches here, the synchronizer token pattern, encryption based token pattern, or HMAC based token pattern. All three of these work by generating a cryptographically secure token that is associated with the user’s current session. This token is embedded into the HTML and/or added to request headers/parameters and submitted to the server which is responsible for verifying the existence and validity of this token. The main difference between the three approaches is the data that is used in generating the secure token and how the token is verified. The synchronizer pattern generates a token per session or request and therefore validates the submitted token using the stored value. The encryption pattern generates a token using the user’s ID, timestamp, and nonce and validates the submitted token by validating it and comparing any potentially stored user ID to the submitted one and checking that the timestamp is still valid. The HMAC pattern is similar to the encryption pattern with the exception that it uses a strong HMAC function and includes an additional field for the operation a request is performing.

Another stateless pattern to mitigate CSRF attacks is origin verification. This mechanism works by determining the origin of a request submitted to the server and comparing it against the origin of the request’s destination. If they both match the server accepts the request as valid and if they do not the server throws the request away. The server determines the origin of a request by first using the Origin header, if it is present. The reason for it’s priority is that it will be present in HTTP requests that originate from a HTTPS URL; unlike the Referer header. However, if the Origin header is not present the Referer header is used as a fallback and if neither are present the request will be blocked. The request’s destination can be determined in a number of ways including adding target origin knowledge to your application, using the Host header, or using the X-Forwarded-Host header. The addition of target origin logic into the application directly is the most secure approach as it lives on the server and therefore is a trusted value. Reliance on headers can seem like a potential pitfall but this pattern works because the relied on headers can only be set by browsers as they are on the forbidden headers list. This means that they cannot be altered programmatically by a malicious third-party. This pattern has drawbacks including its reliance on the behavior of external technology and the potential for the Origin header not being included or being set to null.

One more promising mitigation pattern is utilizing the Samesite cookie attribute. This attribute on a cookie can be set to either Strict or Lax. If set to Strict browsers will not attach the cookie to any cross-site requests. If set to Lax the cookie would be attached to any top-level navigation cross-site request that uses a “safe” HTTP method. However, this approach has some known exploits such as malicious third-parties triggering top-level navigations or opening new windows and prerendering. Also, this attribute is relatively new and therefore is not widely supported by all browsers.

Chosen Mitigation Pattern

When assessing both potential mitigation patterns you can see some obvious pros for token based patterns. It is the recommended OWASP approach, it is the most secure, it has the least number of dependencies on assumptions from external technologies. However, it’s main drawback is that it relies on developers remembering to incorporate generated tokens in forms when submitted. This additional overhead in large scale operations is likely to result in engineers forgetting to submit this token. Moving concern from services and into the Envoy layer entirely adds the advantage that CSRF can be dropped into existing architectures that utilize Envoy for their networking layer. Additionally, this eliminates the need to manage handling of key rotation when the secret key is swapped out. While it’s not ideal to rely on behavior of external technology (namely the Origin header) since this header is relied on for other functionality it seems like a safe assumption this value won’t change in the near future.

Implementation

An HTTP filter will be added to Envoy that will parse incoming requests to determine their origin. This will be done by first checking for the presence of an Origin header and grabbing it’s value if present. In the absence of this header the filter will check for the Referer header and, if available, grab it’s value. In the scenario where both are absent the request will be rejected. Upon rejection a 403 will be returned to the client. If one or both headers are present we will determine the destination origin using the

The filter assumes that consumers aren’t using GET requests for state changing operations, which would violate RFC2616, section 9.1.1.

[mattklein123]

@jmarantz any interest in doing first pass on this? I can do second pass.

[lizan]

starting from some API level comment.

[dschaller]

@lizan thanks for the review. Pushed an update to use per_route_config instead of adding a csrf field on the route config.

[dschaller]

@lizan @mattklein123 any chance I can get some eyes on this? :)

[jmarantz]

I'm taking a pass now; sorry for the delay.

[jmarantz]

There's some really great doc in here. You probably said this in the doc somewhere, but the threat model here is social engineering to trick users into clicking on evil URLs that run unexpected requests on sites they have cookies for, and Envoy can provide protection for this if it's used anywhere in the path between client and origin (or ultimate upstream). Is that right?

[dschaller]

@jmarantz thanks for the review!

the threat model here is social engineering to trick users into clicking on evil URLs that run unexpected requests on sites they have cookies for, and Envoy can provide protection for this if it's used anywhere in the path between client and origin (or ultimate upstream). Is that right?

That's the gist of it. More specifically the unexpected requests generally involve modification requests to user's account through put, post, or delete methods.

[dschaller]

/retest

[repokitteh-read-only]

🔨 rebuilding ci/circleci: coverage (failed build)

🐱

Caused by: a #6470 (comment) was created by @dschaller.

see: more, trace.

[dschaller]

@mattklein123 any chance you can take a second pass over this?

[dschaller]

/retest

[repokitteh-read-only]

🔨 rebuilding ci/circleci: release (failed build)

🐱

Caused by: a #6470 (comment) was created by @dschaller.

see: more, trace.

[dschaller]

/retest

[repokitteh-read-only]

🔨 rebuilding ci/circleci: release (failed build)

🐱

Caused by: a #6470 (comment) was created by @dschaller.

see: more, trace.

[lizan]

Can you merge latest master to see if the release test flakiness is fixed?

[dschaller]

/retest

[repokitteh-read-only]

🔨 rebuilding ci/circleci: coverage (failed build)

🐱

Caused by: a #6470 (comment) was created by @dschaller.

see: more, trace.

[lizan]

Code LGTM, per extension policy I think we need an entry in CODEOWNERS, @dschaller did you discuss with @mattklein123 for the extension sponsorship?

[jmarantz]

@yanavlasov who is interested in security topics.

I think the PR looks pretty good (modulo trivial nits) but I'm not entirely clear what threat-model this is protecting from.

[yanavlasov]

This method references member variables, which means they have to be defined before the config_ variable. Could you leave a comment about the correct order of member definitions, please?

[dschaller]

Can you elaborate on what you're asking for? The proto api documentation should include the fields that are required for using this filter. From a technical standpoint there is no preferred order to these setters.

[yanavlasov]

You have implicit order of definition of member variables of the CsrfFilterTest class. For instance the filter_ must be defined after config_ which must be defined after stats_ and runtime_ members. Otherwise filter_ or config_ would be initialized using references to uninitialized objects. If someone accidentally changes that order the test could become flaky or crash.

[dschaller]

I'm wondering how someone could change the order. The filter requires a configuration, the configuration requires a policy, stat prefix string, stat object, and runtime object. I could be wrong but I think the test would fail if I changed the ordering of any of these. Does that sound right?

[mattklein123]

We do this all over the place so I think this is fine.

[yanavlasov]

Looks good. It would be interesting to see case study for deploying this filter for an already existing app.

[dschaller]

Thanks for the review @lizan, @jmarantz, and @yanavlasov.

@lizan - I did not discuss extension sponsorship with @mattklein123. Let me chat with him offline about this.

@jmarantz can I help clarify anything around what threat-model this is protecting? I attempted to address this in the description but it's possible that I didn't do so in a clear way. :)

@yanavlasov - I could look into that. My goal after adding this filter is to deploy it to our cluster at Lyft, replacing the existing distributed CSRF logic we have today.

[jmarantz]

RE threat-model -- I read your excellent PR description but I was trying to place myself in the position of an attacker, submitting a forged request on the user's behalf. How would that be prevented?

I think in the past I've relied on an encrypted token generated when displaying a form, which expires after some amount of time. That way anyone intercepting the HTTP POST could modify and play it back, but that attack would last only as long as we chose to make the timeout.

If an attacker somehow sniffs an HTTP POST in this scenario, what stops the attacker from playing back an altered form of it, including all the request headers you are utilizing? I don't understand how browsers disallowing modification of some headers would help -- the HTTP client doing the attack need not be a browser that cares about such restrictions.

[dschaller]

Thanks for the reading through that @jmarantz. :) I'm going to try to address everything but let me know if I miss something.

CSRF is an attack that only occurs within a user's web browser. This is primarily because requests that enforce CSRF protection (PUT, POST, and DELETE) require authentication, which usually stores user data in the user's session or as secure cookies. Since most sites automatically include the sensitive data provided by authenticating in all browser requests there is no way to know if the request containing the user's data is coming from a trusted source or a malicious one. CSRF is not intended to mitigate malicious non-browser based requests. This is because if the malicious party was able to retrieve the required session data and cookies they could make a request on the user's behalf.

Let's take the token-based mitigation pattern that you mentioned above. Generally, the issued tokens are sent with every response as a cookie. If I am able to sniff a user's request and find their session ID I would be able to make a GET request to any endpoint, get a new CSRF token, and make a subsequent POST request on their behalf.

The main purpose of CSRF is to prevent sites from spoofing a request on the user's behalf within a browser. For example, if a user ventures onto my malicious site, which appears harmless to them, I could dispatch requests from the browser to google.com and all the credentials associated with that site would be sent along. The destination, in this case google.com, would consider the request valid without CSRF because there is nothing that says it's not intentional. With the chosen CSRF mitigation pattern applied the request would fail due to the Origin header being set as my site and not google.com.

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].1 This filter forwarded all of David Airey’s email to the attacker’s email address, which allowed the attacker to assume control of davidairey.com because Airey’s domain registrar used email authentication, leading to significant inconvenience and financial loss.

[jmarantz]

I see. The threat model you are defending against is when you trick someone to run attacker-controlled JavaScript on a logged-in domain. Separate defenses are needed to avoid being able to sniff requests from outside the browser and forge modifications of them.

Can you include a reference to the quote about gmail in the doc? Otherwise LGTM.

[dschaller]

Just as an update, I sync'ed with @mattklein123 offline and he is ok with sponsoring this extension.

[mattklein123]

Skimmed through and looks awesome. Great work! Let's ship and iterate if needed. Thank you!