GHSA-7wh8-jrq7-p27f: SimpleSAMLphp exposes credentials in session storage

When an authentication request is received via the ECP profile, the username and password obtained this way were saved to the state array, which is used to pass relevant data to different routines that may need it. This is not a problem in itself. However, when the ECP profile is disabled in the Identity Provider, other bindings such as HTTP-POST or HTTP-Redirect will be used, and since redirections are involved, the state array is then persisted to the user’s session, effectively storing it in the session backend.

The ECP profile, which uses the SOAP and PAOS bindings, does not involve any HTTP redirection for the user, and for that reason the state array containing the credentials is never persisted to the session. The logic for determining when to save the credentials to the state array assumed wrongly, though, that if the authentication request came in on the SOAP binding, that means the ECP profile is used. This may not be true as ECP can be disabled by configuration in the IdP’s hosted SAML metadata, and in that case SimpleSAMLphp would then try to default to a binding different than PAOS, such as HTTP-POST or HTTP-Redirect, effectively consolidating the entire state array to the user’s session as described before.

In practice, any Identity Provider with the ECP profile disabled but metadata for an entity that supports ECP, would reject incoming ECP requests, but write the credentials obtained in the request to the user’s session, which will be stored in the session store, whichever is used (local file system in case PHP sessions are used, Memcache, Redis, relational databases, etc).