From beb90ba8a63a33be8173925bdaf01c5a32aad0aa Mon Sep 17 00:00:00 2001 From: exceptionfactory Date: Thu, 22 Dec 2022 22:51:43 -0600 Subject: [PATCH] NIFI-10855 Added Documentation on CSRF Protection Signed-off-by: Pierre Villard This closes #6805. --- .../main/asciidoc/administration-guide.adoc | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/nifi-docs/src/main/asciidoc/administration-guide.adoc b/nifi-docs/src/main/asciidoc/administration-guide.adoc index 5829b4dbf7..e1cbbea80e 100644 --- a/nifi-docs/src/main/asciidoc/administration-guide.adoc +++ b/nifi-docs/src/main/asciidoc/administration-guide.adoc @@ -582,6 +582,42 @@ The following settings can be configured in _nifi.properties_ to control JSON We |`nifi.security.user.jws.key.rotation.period` | JSON Web Signature Key Rotation Period defines how often the system generates a new RSA Key Pair, expressed as an ISO 8601 duration. The default is one hour: `PT1H` |================================================================================================================================================== +[[csrf-protection]] +=== Cross-Site Request Forgery Protection + +NiFi 1.15.0 introduced +link:https://owasp.org/www-community/attacks/csrf[Cross-Site Request Forgery] protection as part of user interface +access based on session cookies. CSRF protection builds on standard +link:https://docs.spring.io/spring-security/reference/features/exploits/csrf.html[Spring Security features] +and implements the +link:https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie[double submit cookie] +strategy. The implementation strategy relies on the server generating and sending a random request token cookie at the +beginning of the session. The client browser stores the cookie, JavaScript application code reads the cookie, and sets +the value in a custom HTTP header on subsequent requests. + +NiFi applies the `SameSite` attribute with a value of `Strict` to session cookies, which instructs supporting web +browsers to avoid sending the cookie on requests that a third party initiates. These protections mitigate a number of +potential threats. + +Cookie names are not considered part of the public REST API and are subject to change in minor release +versions. Programmatic HTTP requests to the NiFi REST API should use the standard HTTP `Authorization` header when +sending access tokens instead of the session cookie that the NiFi user interface uses. + +NiFi deployments that include HTTP load balanced access with <> depend on custom HTTP cookies, +requiring custom programmatic clients to store and send cookies for the duration of an authenticated session. +Programmatic clients in these scenarios should limit cookie storage to cookie names specific to the HTTP load balancer +to avoid HTTP 403 Forbidden errors related to CSRF filtering. + +The CSRF implementation sends the following HTTP cookie to set the random request token for the session: + +- Cookie Name: `__Secure-Request-Token` +- Value: Random UUID + +The CSRF security filter expects the following HTTP request header on non-idempotent methods such as `POST` or `PUT`: + +- Header Name: `Request-Token` +- Value: UUID matching the `__Secure-Request-Token` cookie header + [[multi-tenant-authorization]] == Multi-Tenant Authorization