CSRF FlowExecutionListener testing for CAS
Purpose
Following on from CSRF Mitigation Options, here we test that the CsrfFlowExecutionListener
[1] CSRF synchroniser token pattern mitigation works when using the IdP as a CAS server.
Views
The following CAS views have been tested with CSRF protection enabled.
View Name | Description | Requires CSRF protection e.g. uses HTML Form POST to the IdP |
---|---|---|
footer.vm | XML cas service response footer | No |
header.vm | XML cas service response header | No |
logoutService.vm | Propogates a CAS logout to the SP | No/Yes. Main form is posted to the SP with a SAML 2 logout request hence CSRF token is not required. However, the underlaying flow itself is finalised by directing the propagation iFrame back to the IdP and resuming the conversation. This is done by modifying the iFrame src, and requires the CSRF token in the URL set into the sessionStorage e.g. see U1. Alternatively you could exclude this view (ShowServiceLogoutView)Â from CSRF protection - probably makes sense. |
postBack.vm | When service ticket request method is POST | No. Main form is posting the service ticket to the SP, hence an CSRF token is not required from the IdP. |
proxyFailure.vm | XML cas proxy failure response | No |
proxySuccess.vm | XML cas proxy success response | No |
validateFailure.vm | XML cas authentication failure response | No |
validateSuccess.vm | XML cas authentication success response | No |
U1
Modify the script in the CAS logoutService.vm to include the csrftoken:
<script> if (typeof(Storage) !== "undefined") { sessionStorage.setItem("$logoutPropCtx.sessionKey", "$flowExecutionUrl&_eventId=proceed&${csrfToken.parameterName}=${csrfToken.token}"); } </script>