[
https://issues.apache.org/jira/browse/NIFI-10871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Palfy updated NIFI-10871:
-------------------------------
Fix Version/s: 1.20.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Intermittent CSRF HTTP 403 in Clustered Deployments
> ----------------------------------------------------
>
> Key: NIFI-10871
> URL: https://issues.apache.org/jira/browse/NIFI-10871
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI, Security
> Affects Versions: 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Major
> Fix For: 1.20.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> NiFi 1.14.0 introduced Cross-Site Request Forgery mitigation as part of
> updates to support JSON Web Token resolution using HttpOnly Session cookies.
> The standard Spring Security
> [CsrfFilter|https://github.com/spring-projects/spring-security/blob/5.7.5/web/src/main/java/org/springframework/security/web/csrf/CsrfFilter.java]
> includes a Request Matcher property to control whether filtering operations
> should be applied, but the CsrfFilter checks the Request Matcher after
> generating and saving a new token.
> Standalone deployments of NiFi can reuse the CSRF Request Token when the HTTP
> request includes the value in a {{Cookie}} header, but the NiFi HTTP Request
> Replicator removes the CSRF Request Token cookie before sending the request
> to other cluster nodes.
> As a result of these implementation details, NiFi cluster nodes receiving
> replicated HTTP requests generate and return a new CSRF Request Token. The
> NiFi user interface receives the new CSRF Request Token and uses it to set
> the custom {{Request-Token}} HTTP Header on subsequent requests. This is not
> an issue for HTTP GET requests, but requests using methods such as POST, PUT,
> or DELETE can return an HTTP 403 Forbidden response from the Spring Security
> CsrfFilter due to receiving mismatched {{__Secure-Request-Token}} Cookie and
> {{Request-Token}} Header values.
> This issue is intermittent because it depends on the web browser
> simultaneously receiving an HTTP response with a new Secure-Request-Token
> Cookie while preparing to send a new HTTP request with a {{Request-Token}}
> Header that contains the value from the previously received cookie.
> Resolving the problem should include adjusting the behavior of the CsrfFilter
> to avoid setting a new cookie on requests that do not require filtering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
