Possible CSRF attack on login (maybe)

12 views
Skip to first unread message

Ben Martin

unread,
May 20, 2019, 3:18:01 AM5/20/19
to SimpleSAMLphp developers
Hi,

  As part of a security audit on a live site it was reported that there was a CSRF vulnerability with the following URL. I think the version of SimpleSAMLphp the site was using was around 6 months old. I have been trying to produce an effective attack on a local installation to verify that it can happen. I have also been digging into the code to try to see how it might happen and can be mitigated if it does happen.

The URL in question is a POST method to
.../simplesaml/module.php/saml/sp/saml2-acs.php/default-sp

It was reported as follows:
  An attacker can log himself in on a user’s device. If the user does not notice the change in user name, any further actions the user makes will be made on the attacker’s account. This allows the attacker to see any data entered by the user in the system from this point in time.

To resolve CSRF in the SAML log-in flow, the following steps should be taken:
1. Store the ID value from the SAML AuthnRequest in the user’s session
2. Retrieve the InResponseTo value from the SAML Response, and verify if it matches with the ID value stored in the session.

...
Any thoughts on if this scenario is already protected at the SimpleSAMLphp level are very welcome.

Thijs Kinkhorst

unread,
May 20, 2019, 3:38:31 AM5/20/19
to simplesa...@googlegroups.com
Hi Ben,

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
SAML flow.

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.


Cheers,
Thijs

Pieter van der Meulen

unread,
May 20, 2019, 9:25:20 AM5/20/19
to SimpleSAMLphp developers
Hi,

There should be replay protection in SSP agains using the same Assertion twice, even when the SAML IdP initiated flow (aka unsolicited assertions) is used, however this requires persistent storage to be available over all SP instances. Jaime did an extensive writeup of how this is implemented in
https://github.com/simplesamlphp/simplesamlphp/issues/230#issuecomment-123644732

When the SP initiated flow is used, you should always be protected against replay.
> --
> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp-...@googlegroups.com.
> To post to this group, send email to simplesa...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp-dev.
> To view this discussion on the web visit https://groups.google.com/d/msgid/simplesamlphp-dev/d1e5e30e-4e62-45de-9f3b-6631c1708545%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Groet,

Pieter.

--
Pieter van der Meulen (Pieter.va...@surfnet.nl)
SURFnet (Trust & Security) - www.surfnet.nl


signature.asc

Thijs Kinkhorst

unread,
May 20, 2019, 9:41:33 AM5/20/19
to simplesa...@googlegroups.com
Op 20-05-19 om 15:25 schreef Pieter van der Meulen:
> There should be replay protection in SSP agains using the same Assertion twice, even when the SAML IdP initiated flow (aka unsolicited assertions) is used, however this requires persistent storage to be available over all SP instances. Jaime did an extensive writeup of how this is implemented in
> https://github.com/simplesamlphp/simplesamlphp/issues/230#issuecomment-123644732

If this would be possible, it would not solve the unsolicited SSO
scenario. After all, there is no need for the attacker to let his
assertion actually reach the actual SP for him to be able to repurpose it
with the victim.


Cheers,
Thijs

Pieter van der Meulen

unread,
May 20, 2019, 10:04:12 AM5/20/19
to simplesa...@googlegroups.com
True.

Would it make sense then to allow unsolicited assertions to be disabled on the SP though configuration? 

It is an, for SPs, unexpected feature in my experience.

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlphp-...@googlegroups.com.
To post to this group, send email to simplesa...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp-dev.

For more options, visit https://groups.google.com/d/optout.

Pieter.
signature.asc

Tim van Dijen

unread,
May 20, 2019, 11:35:09 AM5/20/19
to SimpleSAMLphp developers
I would very much like such option! It was even discussed earlier, just never implemented..
At this point SAML2INT mandates that SPs should accept unsolicited assertions, but they seem to have dropped that in the 2.0 draft..

Op maandag 20 mei 2019 16:04:12 UTC+2 schreef Pieter van der Meulen:
True.

Would it make sense then to allow unsolicited assertions to be disabled on the SP though configuration? 

It is an, for SPs, unexpected feature in my experience.
On 20 May 2019, at 15:41, Thijs Kinkhorst <thijs.k...@surfnet.nl> wrote:

Op 20-05-19 om 15:25 schreef Pieter van der Meulen:
There should be replay protection in SSP agains using the same Assertion twice, even when the SAML IdP initiated flow (aka unsolicited assertions) is used, however this requires persistent storage to be available over all SP instances. Jaime did an extensive writeup of how this is implemented in
https://github.com/simplesamlphp/simplesamlphp/issues/230#issuecomment-123644732

If this would be possible, it would not solve the unsolicited SSO
scenario. After all, there is no need for the attacker to let his
assertion actually reach the actual SP for him to be able to repurpose it
with the victim.


Cheers,
Thijs

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesa...@googlegroups.com.

Pieter.
Reply all
Reply to author
Forward
0 new messages