Op 20-05-19 om 09:18 schreef Ben Martin:
This is a supported feature of the SAML 2.0 protocol, not a vulnerability.
It is called "unsolicited SSO" or "IdP first".
It means that the IdP sends a valid assertion to the SP "out of the blue",
i.e. without any authnrequest having taken place.
So the 'attack' scenario is this:
- The attacker "eve" needs a valid account at the IdP. The attacker logs
in to the SP and stores the signed assertion.
- The attacker then sends the victim to a URL under his control. The URL
posts the still valid assertion (typically valid for 5 minutes) to the SP.
The SP will consider the user "eve" to be logged in because it's a valid
In order to be successful, it depends on a guillible user. The user is
unexpectedly and suddenly "logged into" filesender. Filesender will
display the name of eve, not of the user. The user will then have to not
notice that this is the case, AND start doing something that is valuable,
e.g. upload a file.
IMO the 'attack' scenario is rather contrived - it seems unlikely that
you'd be logged into filesender by surprise and then still think "oh,
that's convenient, let's start uploading something" (and also not notice
that it's not your name that is in the interface).
Because it's a protocol feature, I don't think your suggested steps to
solve it will help here since by definition there's no AuthnRequest in
SAML unsolicited SSO.
In any case it's something most SAML implementations supports because it's
an aspect of the protocol. E.g. the same "attack" is possible with
Shibboleth, and it has no way to disable it.