CSRF FlowExeuctionListener testing, all views overview

fo

Status

I think there are now a complete set of views.

Key

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

	Flow	view ID	view name	velocity template	HTML Form POST	Requires CSRF token	Checked Working	Include, Exclude (black-list from checks), or ignore (no sensitive data post) from CSRF check
1	/admin/unlock-keys-flow.xml	PromptForPasswords	admin/unlock-keys	unlock-keys.vm	yes	yes	Yes	Include, although of little risk.
2	/intercept/impersonate-flow.xml	ImpersonateView	#{flowRequestContext.activeFlow.id}	Yes	Yes	Yes for both ‘impersonate’ proceed event, and continue normally ‘proceed’ event.	Yes	Include (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.xml	DisplayAttributeReleasePage	#{flowRequestContext.activeFlow.id}	attribute-release.vm	Yes	Yes for the standard ‘proceed’ transition, not currently triggered if attribute release is rejected.	Yes	Include. Attacker could force consent if the user paused and navigated to a malicious page etc. on that view-state
4	/intercept/external-flow.xml	ExternalTransfer	externalRedirect:#…getBean(‘shibboleth.intercept.externalPathStrategy’)…	NA	NA	See external-authentication-testing for options	NA	Exclude
5	/intercept/terms-of-use-flow.xml	DisplayTermsOfUsePage	#{flowRequestContext.activeFlow.id}	terms-of-user.vm	Yes	Yes for ‘proceed’, not checked on ‘TermsRejected’ transition	Yes	Include
6	/intercept/expiring-password-flow.xml	DisplayExpiringPasswordView	#{flowRequestContext.activeFlow.id}	expiring-password.vm	No, although there is a ‘proceed’ meta refresh (redirect), and hyperlink back to the IdP	Yes	The csrf token can be appended to the hyperlink or refresh URL by velocity	Exclude, is auto-submitted anyway
7	/logout/propagation/cas-flow.xml	ShowServiceLogoutView	cas/logoutService	logoutService.vm	Yes	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.	Yes	Exclude.
8	/logout/logout-flow.xml	LogoutView	logout	logout.vm	Yes	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. $flowExecutionUrl&_eventId=proceed#if($csrfToken)&${csrfToken.parameterName}=${csrfToken.token}#{else}#end" 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.	Yes	Exclude.
9	/logout/logout-flow.xml	LogoutPropagateView	logout-propagate	logout-propagate.vm, propogate.vm	No, although uses iFrames to propagate logout via different mechanisms	Mechanism 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).	Yes	Ignore. not needed directly on these views. Check propagation views. Although check hidden iframe usage more.
10	/logout/logout-flow.xml	LogoutCompleteView	logout-complete	logout-complete.vm	No	No	Yes	Ignore. not needed.
11	/client-storage/client-storage-read-flow.xml	LocalStorageRead	/client-storage/client-storage-read	client-storage-read.vm, read.vm	Yes, in read.vm	Yes	Yes	Include
12	/client-storage/client-storage-write-flow.xml	LocalStorageWrite	/client-storage/client-storage-write	local-storage-write.vm, write.vm	Yes, in write.vm	Yes	Yes	Include
13	/authn/spnego-authn-flow.xml	RunSPNEGO	externalRedirect:#…getBean(‘shibboleth.authn.SPNEGO.externalAuthnPathStrategy’)…	NA	NA	Kerberos 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.	NA	Exclude
14	/authn/duo-authn-flow.xml	DisplayDuoWebView	duo	duo.vm	Yes, `duo_form`	Yes	Yes	Include.
15	/authn/remoteuser-authn-flow.xml	ExternalTransfer	externalRedirect:#…getBean(‘shibboleth.authn.RemoteUser.externalAuthnPathStrategy’)…	NA	NA	see external-authentication-testing for options for options	NA	Exclude
16	/authn/x509-authn-flow.xml	ExternalTransfer	externalRedirect:#…getBean(‘shibboleth.authn.X509.externalAuthnPathStrategy’)…	x509-prompt.jsp (Default)	Yes	X509 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.	NA	Exclude
17	/authn/password-authn-flow.xml	DisplayUsernamePasswordPage	login	login.vm	Yes	Yes	Yes	Include
18	/authn/external-authn-flow.xml	ExternalTransfer	externalRedirect:#…getBean(‘shibboleth.authn.External.externalAuthnPathStrategy’)…	NA	NA	See external-authentication-testing for options	NA	NA
19	/saml/saml2/slo-front-abstract-flow.xml	LogoutView	logout	logout.vm	Yes	Yes, 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*	Yes	Exclude
20	/saml/saml2/slo-front-abstract-flow.xml	LogoutPropagateView	logout-propagate	logout-propagate.vm, propogate.vm	See (9)	See (9)	See (9)	See (9)
21	/saml/saml2/slo-front-abstract-flow.xml	LogoutCompleteView	logout-complete	logout-complete.vm	No	No	Yes	Ignore. not needed.
22	authn/conditions/expiring-password/expiring-password-flow.xml	ExpiringPassword	intercept/expiring-password	expiring-password.vm	No, although there is a ‘proceed’ meta refresh (redirect), and hyperlink back to the IdP	Yes	The csrf token can be appended to the hyperlink or refresh URL by velocity	Exclude, is auto-submitted anyway
23	/admin/status-flow.xml	Status	status	status.jsp	No	NA	NA	NA
24	/admin/mdquery-flow.xml	ResponseView	mdquery	mdquery.vm	No	NA	NA	NA
25	/user/prefs/prefs-flow.xml	RenderView	user-prefs	user-prefs.vm	No	NA	NA	NA
26	Generic	ErrorView	error	error.vm (dynamic)	No	NA	NA	NA
27	/saml/saml2/slo-front-abstract-flow.xml	AsyncLogoutView	logout/saml-async	saml-async.vm	No	NA	NA	NA
28	/saml/saml2/slo-front-abstract-flow.xml	LogoutResponseView	logout/saml-result	saml-result.vm	No	NA	NA	NA

++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.

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>