Spring Security <websocket-message-broker> should use XorCsrfChannelInterceptor by default

Describe the bug When configuring WebSocket message security via Spring Security's XML support, a CsrfChannelInterceptor is configured but the default CSRF handler in the web layer is generated by the XorCsrfTokenRequestAttributeHandler, so STOMP CONNECT messages that present the XOR'd CSRF value are rejected as a mismatch.

To Reproduce Configure WebSocket security via XML with basic defaults, for example:

<websocket-message-broker>
    <intercept-message type="CONNECT" access="permitAll" />
    <intercept-message type="UNSUBSCRIBE" access="permitAll" />
    <intercept-message type="DISCONNECT" access="permitAll" />
    <intercept-message pattern="/pub/**" access="permitAll" />
    <intercept-message pattern="/**" access="hasRole('USER')" />
</websocket-message-broker>

When a client that has authenticated successfully with Spring Security tries to issue a STOMP CONNECT request, passing in the active session-based CSRF value generated by Spring Security's .web.csrf.XorCsrfTokenRequestAttributeHandler the message is rejected and the connection terminated.

Expected behavior I thought Spring Security 6 could switch to defaulting to .messaging.web.csrf.XorCsrfChannelInterceptor now instead of .messaging.web.csrf.CsrfChannelInterceptor, in WebSocketMessageBrokerSecurityBeanDefinitionParser e.g.

if (!this.sameOriginDisabled) {
    interceptors.add(new RootBeanDefinition(XorCsrfChannelInterceptor.class));
}

Work-around

I couldn't find a simple way to use XorCsrfChannelInterceptor so I added a basic BeanPostProcessor to my application that replaced the CsrfChannelInterceptor instance with an XorCsrfChannelInterceptor instance on the ExecutorSubscribableChannel bean.

Comment From: jzheaux

This is likely an oversight as WebSocketMessageBrokerSecurityConfiguration also changed its default. That said, it would break passivity to change the default interceptor in XML at this point.

We can make this change in main and also publish your workaround in the migration guide. Are you able to contribute a PR that does that?

Comment From: msqr

Hey @jzheaux I'm happy to put together a PR -- did you mean for the WebSocketMessageBrokerSecurityBeanDefinitionParser class or the migration guide, or both?

Comment From: jzheaux

Both if you are up to it, @msqr. I'm happy to team up as well.

Comment From: msqr

Ok, I started PR #17323 with the code change. Where would the documentation be updated, would you be referring to migration/index.adoc?