You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by GitBox <gi...@apache.org> on 2022/12/23 13:48:59 UTC

[GitHub] [nifi] Lehel44 commented on a diff in pull request #6805: NIFI-10855 Add Documentation on CSRF Protection

Lehel44 commented on code in PR #6805:
URL: https://github.com/apache/nifi/pull/6805#discussion_r1056337558


##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.

Review Comment:
   In case someone goes through the documentation but now aware of what CSRF is we may leave a brief introduction or a link for the context.
   "[Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site when the user is authenticated."



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The

Review Comment:
   If we can add links, I'd add https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie to the double submit cookie strategy.



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The
+implementation strategy relies on sending a random request token cookie at the beginning of the session, and requiring
+the JavaScript user interface to send the value in a corresponding request header. NiFi applies the `SameSite`
+attribute with a value of `strict` to the authorization session cookie, 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, which
+requires custom programmatic clients to store and send cookies for the duration of an authenticated session.

Review Comment:
   ```suggestion
   NiFi deployments that include HTTP load-balanced access with <<session_affinity>> depend on custom HTTP cookies, which
   require custom programmatic clients to store and send cookies for the duration of an authenticated session.
   ```



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The
+implementation strategy relies on sending a random request token cookie at the beginning of the session, and requiring
+the JavaScript user interface to send the value in a corresponding request header. NiFi applies the `SameSite`
+attribute with a value of `strict` to the authorization session cookie, which instructs supporting web browsers to

Review Comment:
   Not sure if it matters but in the examples the SameSite cookie values start with capital letter.



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The
+implementation strategy relies on sending a random request token cookie at the beginning of the session, and requiring
+the JavaScript user interface to send the value in a corresponding request header. NiFi applies the `SameSite`
+attribute with a value of `strict` to the authorization session cookie, 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, which
+requires 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
+in order to avoid HTTP 403 Forbidden errors related to CSRF filtering.

Review Comment:
   ```suggestion
   to avoid HTTP 403 Forbidden errors related to CSRF filtering.
   ```



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The
+implementation strategy relies on sending a random request token cookie at the beginning of the session, and requiring
+the JavaScript user interface to send the value in a corresponding request header. NiFi applies the `SameSite`

Review Comment:
   Do we need "JavaScript" at "user interface".



##########
nifi-docs/src/main/asciidoc/administration-guide.adoc:
##########
@@ -582,6 +582,36 @@ 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 Cross-Site Request Forgery protection as part of user interface access based on session cookies.
+CSRF protection builds on a standard Spring Security Filter and implements the double submit cookie strategy. The
+implementation strategy relies on sending a random request token cookie at the beginning of the session, and requiring

Review Comment:
   I'd specify the parties here, who sends what to who. NiFi webserver generates a random value cookie and set it as a cookie on the client's machine at beginning of the sessions. The same value is required to send in the request header for CSRF protection.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org