This is an automated email from the ASF dual-hosted git repository.
pvillard pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/nifi.git
The following commit(s) were added to refs/heads/main by this push:
new beb90ba8a6 NIFI-10855 Added Documentation on CSRF Protection
beb90ba8a6 is described below
commit beb90ba8a63a33be8173925bdaf01c5a32aad0aa
Author: exceptionfactory <[email protected]>
AuthorDate: Thu Dec 22 22:51:43 2022 -0600
NIFI-10855 Added Documentation on CSRF Protection
Signed-off-by: Pierre Villard <[email protected]>
This closes #6805.
---
.../src/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
<<session_affinity>> 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
