CSRF FlowExeuctionListener testing, all views overview



I think there are now a complete set of views.


  • Green - works.
  • Yellow - CSRF not required, no form posts or to complex to include etc.
  • Red - not working
  • White - in testing or not sure.

Flowview IDview namevelocity templateHTML Form POSTRequires CSRF tokenChecked WorkingInclude, Exclude (black-list from checks), or ignore (no sensitive data post) from CSRF check
1/admin/unlock-keys-flow.xmlPromptForPasswordsadmin/unlock-keysunlock-keys.vmyesyesYesInclude, although of little risk.
2/intercept/impersonate-flow.xmlImpersonateView#{flowRequestContext.activeFlow.id}YesYesYes for both ‘impersonate’ proceed event, and continue normally ‘proceed’ event.YesInclude (requires listening to new eventId). Theoretically an attacker could change the (POST a new) principal to impersonate, but they are limited to those that satisfy an appropriate impersonation policy - so of little benefit to an attacker. Note, would need to include ‘impersonate’ eventId to include to work.
3/intercept/attribute-release-flow.xmlDisplayAttributeReleasePage#{flowRequestContext.activeFlow.id}attribute-release.vmYesYes for the standard ‘proceed’ transition, not currently triggered if attribute release is rejected.YesInclude. Attacker could force consent if the user paused and navigated to a malicious page etc. on that view-state
4/intercept/external-flow.xmlExternalTransferexternalRedirect:#…getBean(‘shibboleth.intercept.externalPathStrategy’)…NANASee external-authentication-testing for optionsNAExclude
5/intercept/terms-of-use-flow.xmlDisplayTermsOfUsePage#{flowRequestContext.activeFlow.id}terms-of-user.vmYesYes for ‘proceed’, not checked on ‘TermsRejected’ transitionYesInclude
6/intercept/expiring-password-flow.xmlDisplayExpiringPasswordView#{flowRequestContext.activeFlow.id}expiring-password.vmNo, although there is a ‘proceed’ meta refresh (redirect), and hyperlink back to the IdPYesThe csrf token can be appended to the hyperlink or refresh URL by velocityExclude, is auto-submitted anyway
7/logout/propagation/cas-flow.xmlShowServiceLogoutViewcas/logoutServicelogoutService.vmYesNo/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.YesExclude.

You could do it to help prevent CSRF attackers from forcing a global logout, although to do this you also need to conditionally add to the hidden iframes e.g.


However, once the IdPs logout page has been requested, you are logged out of the IdP locally before a view is shown. Hence, it becomes the responsibility of the SP to ensure a 'logout' button is not triggered cross-site. Given the intricacies of adding the token to the iframes, there being little benefit in adding the token (you are already locally logged out), and the fact that login CSRF should be protected, this can be excluded.

9/logout/logout-flow.xmlLogoutPropagateViewlogout-propagatelogout-propagate.vm, propogate.vmNo, although uses iFrames to propagate logout via different mechanismsMechanism dependant e.g. SAML2 propagation  does a GET to SP (or SOAP POST) followed by a REDIRECT back to the IdP to start a new conversation, and does not need CSRF tokens. The CAS logout flow resumes the existing IdP conversation and so does need a CSRF token  unless excluded (see cas/logoutService).YesIgnore. not needed directly on these views. Check propagation views. Although check hidden iframe usage more.
10/logout/logout-flow.xmlLogoutCompleteViewlogout-completelogout-complete.vmNoNoYesIgnore. not needed.
11/client-storage/client-storage-read-flow.xmlLocalStorageRead/client-storage/client-storage-readclient-storage-read.vm, read.vmYes, in read.vmYesYesInclude
12/client-storage/client-storage-write-flow.xmlLocalStorageWrite/client-storage/client-storage-writelocal-storage-write.vm, write.vmYes, in write.vmYesYesInclude
13/authn/spnego-authn-flow.xmlRunSPNEGOexternalRedirect:#…getBean(‘shibboleth.authn.SPNEGO.externalAuthnPathStrategy’)…NANAKerberos tickets themselves are a form of ambient authority, and can be exploited by CSRF attacks once logged in (although this does not apply directly to the IdP, CSRF should be managed on the SP). However, there is no way I know of (unless by other means e.g. careful XSS or social engineering) for an attacker to change the Kerberos ticket to perform Login CSRF (logging in as the attacker) to the IdP.  NAExclude
14/authn/duo-authn-flow.xmlDisplayDuoWebViewduoduo.vmYes, duo_formYesYesInclude.
15/authn/remoteuser-authn-flow.xmlExternalTransferexternalRedirect:#…getBean(‘shibboleth.authn.RemoteUser.externalAuthnPathStrategy’)…NANAsee external-authentication-testing for options for optionsNAExclude

x509-prompt.jsp (Default)

YesX509 certs themselves are a form of ambient authority, and can be exploited by CSRF attacks once logged in (although this does not apply directly to the IdP, CSRF should be managed on the SP). CSRf tokens could be added, see external-authentication-testing for options. Although an attacker should not be able to change a browser client certificate simply from a cross-site request. Worst they could do is force a user to login (using the users certificate, not the attackers) and or revokeConset, allow passthrough. NAExclude
18/authn/external-authn-flow.xmlExternalTransferexternalRedirect:#…getBean(‘shibboleth.authn.External.externalAuthnPathStrategy’)…NANASee external-authentication-testing for optionsNANA
19/saml/saml2/slo-front-abstract-flow.xmlLogoutViewlogoutlogout.vmYesYes, although there are four possible transition events, ‘end’, local’, ‘propogate’, and ‘proceed’. The token is only currently checked if ‘proceed’ is initiated - which occurs to complete the flow. Other transitions should possibly be included to help prevent logout CSRF*YesExclude
20/saml/saml2/slo-front-abstract-flow.xmlLogoutPropagateViewlogout-propagatelogout-propagate.vm, propogate.vmSee (9)See (9)See (9)See (9)
21/saml/saml2/slo-front-abstract-flow.xmlLogoutCompleteViewlogout-completelogout-complete.vmNoNoYesIgnore. not needed.
22authn/conditions/expiring-password/expiring-password-flow.xmlExpiringPasswordintercept/expiring-passwordexpiring-password.vmNo, although there is a ‘proceed’ meta refresh (redirect), and hyperlink back to the IdPYesThe csrf token can be appended to the hyperlink or refresh URL by velocityExclude, is auto-submitted anyway


errorerror.vm (dynamic)NoNANANA









++This is only possible if the user navigated away from the logout.vm view-state, visited a malicious site which posted a form back to the IdP with correct execution key and eventId of proceed.


Modify the script in the CAS logoutService.vm to include the csrftoken:

    if (typeof(Storage) !== "undefined") {
        sessionStorage.setItem("$logoutPropCtx.sessionKey", "$flowExecutionUrl&_eventId=proceed&${csrfToken.parameterName}=${csrfToken.token}");