Background
In order to implement support for the SAML Enhanced Client or Proxy profile, the credentials obtained for authentication were stored in the state in order to pass them to the relevant routines. This, however, led to the credentials being recorded in the user’s session, which can be stored in permanent storage such as the local file system or a remote memcache or database server.
Description
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).
Affected versions
All SimpleSAMLphp versions 1.16.x are affected, up to 1.16.2.
Impact
An Identity Provider with metadata for trusted entities that support the SAML ECP profile, may end up storing the user’s credentials received from such entities in its own session storage, whatever that is, in case ECP is actually not enabled in the IdP. Under such circumstances, the credentials may be then accessible to administrators, other personnel or even malicious parties who may have access to the systems where sessions or their backups are stored.
References
Background
In order to implement support for the SAML Enhanced Client or Proxy profile, the credentials obtained for authentication were stored in the state in order to pass them to the relevant routines. This, however, led to the credentials being recorded in the user’s session, which can be stored in permanent storage such as the local file system or a remote memcache or database server.
Description
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).
Affected versions
All SimpleSAMLphp versions 1.16.x are affected, up to 1.16.2.
Impact
An Identity Provider with metadata for trusted entities that support the SAML ECP profile, may end up storing the user’s credentials received from such entities in its own session storage, whatever that is, in case ECP is actually not enabled in the IdP. Under such circumstances, the credentials may be then accessible to administrators, other personnel or even malicious parties who may have access to the systems where sessions or their backups are stored.
References