[jira] [Updated] (NIFI-10871) Intermittent CSRF HTTP 403 in Clustered Deployments

["David Handermann (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIFI-10871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Handermann updated NIFI-10871:
------------------------------------
    Status: Patch Available  (was: In Progress)

> 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.18.0, 1.17.0, 1.16.0, 1.15.0, 1.14.0
>            Reporter: David Handermann
>            Assignee: David Handermann
>            Priority: Major
>          Time Spent: 10m
>  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)