SEC-2722: CsrfToken invalidated when using PreAuthenticatedProcessingFilter with checkForPrincipalChanges enabled

Michael Russo (Migrated from SEC-2722) said:

The issue stems CsrfFilter being called before PreAuthenticatedProcessingFilter in the security filter chain. CsrfFilter will detect that a token exists for the (currently valid) session, but the PreAuthenticatedProcessingFilter invalidates the session later in the chain, so a new token won't be generated for the remainder of this request.

This issue is resolved if the PreAuthenticatedProcessingFilter is added before the CsrfFilter in the chain. Then, session invalidation occurs first, so CsrfFilter will correctly generate a new token for this request.

As a side-note, when this situation occurs, the request attribute "_csrf" won't match the session attribute (which was erased), so any view that relies on the request attribute will see an invalid token instead of an empty one. This is because CsrfFilter sets the request attribute immediately and delays adding the session attribute due to SEC-2276

Start by tracing CsrfFilter and PreAuthenticatedProcessingFilter in the security filter chain, focusing on session invalidation, request attributes, and delayed session-token storage described in the issue. Done should ensure that enabling checkForPrincipalChanges does not leave the request with a token from an invalidated session, while preserving the stated filter-order behavior.