CSRF protection for login page

[Paul Roemer]

Hey guys,

we noticed that you can easily create your own login form with copied execution ID on any domain you might want to use for phishing attacks. As for the victim everything looks good (login is successful), detecting the attack is hard.


Example form for the CAS demo server:
<form action="https://casserver.herokuapp.com/cas/login" method="POST">
<input type="hidden" name="username" value="casuser">
<input type="hidden" name="password" value="Mellon">
<input type="hidden" name="execution" value="4966e50b-191f-45e1-bab2-22e6304447c7_ZXlKaGJHY2lPaUpJVXpVeE1pSXNJblI1Y0NJNklrcFhWQ0o5Lk5NV1I3dHVicU1USWZqLW1kb1pnak8tWlctN21XRGVMTk1XMl9fMUczNktRemg4MHNRcEoycHFsa01uYkhGbkdUYmZPWkRmUDZfLXk0UTlLMXFVQjFOb05sbmRod3dPZF9ZS0ctc29BalItMzhlRXdNTXpmdFFTZTE5aEJwQXZVeHBnZGN5LVVtajhPRXFFbVlqRWtwUmpST2QzbC1sN3A4ZXkwU1dVWjBHZHFRMXpYSGRjc19Mc21UODZ0TFY3ZDdCd2dUTWxYZUFzUEotTFRzTGFud05rRjlzenRjVjFrd3dYemgxOU1aQ2lHSEMwWkJTVExGYWxxcGtQNTRQbFNJQ2g4azBmNXdjRGJYYmN3TEdFWmJwUFViS3dDZHFkdGg2NndKQ2pWZUM3R0loVzNfQWVjUWZnLXItU3o4S080MjlKMlN5TU40NlNtT0J5WXh1MnJ2RmZINDJFSm9iM0dOSzQzT0xiZWU1dHUzRzhna3NXRmRibkxWbk1LMXJfSEFnMWNXSC1sUGY2cU53c1liSXR6YlJ2WFlaVm1HUHdjN01XdEdqS09ObFpSNDNjS3hHbkp6UUFaUEZuWmo1LUUyNjlpX1ZuemloT0ZlVEx1SG1GcmRCbTFLb2kxTG9qbDF1ZGpfZkg1dHA2azFiLUQ2QzZibTZ3bTRxY1lZWU03SHlpNGJNYVMtNUVUcHpKbzdmX0E5bW9ZWmoyR0RSMVdxaXA4X2Z3RUpEZUd0eklVdVFJaVpVRUJqRW51RGZ2bFgzWkhva1g0WXU1eTNFUEd2LVpHNWhOSjc1STFFQjVtbE53ckpDdWJwQ2I0QWtMS0w5NXc3UGk5eHVrcFVVVVRpb01NOVVvRnhXMGZtMXAybTdEbFRPTko3Q080M09HcHo0RmRBNnBKRVJQeVd3SFZkOXA5UEhEaUo1b29ybGk0WUY0S1FmYUFQREJyMHZsSjlac0dhNlJSSHkzQnhIa05EMmg5bUlDUDZNZEpmLUhtTDMyWnM2Z2MyODlkZWYxdVlYMnlpMUFONlg3dTQ4R2k3cVd1aElZWnBVNDVTZENpQVp0ejIwWWk5NzFwUFlkamlnUG9UUmRrdDVzM0RHWDQ0ZnJZbnRFTjQxMjlDcDBscUJ0S2E1eGg5bHd5UGNsZW5rcVJYX3JTREk4VE9EUnRTWHRZYmhwMGxlZUVremtMVXVEdmVnVk0yMkNaOWdnUHJHR1ZCZGV3c0lBc0JoWGtoRzhzVUNtTk1HSjNNbHNfdzFRaUpSX3RHN2hMcUEwNVMzVlRrcUJGNEFnVUF2NktXN1hUMGtBNGxDcS1iNzZCR3JielZIMmhPODlTYng2ZUhQZjRDcFJ3VGZOS2dfVzFRdmU3NkVnZm55M3JXYjN6NWRJeXd0LVRvanhWalhPX1VDcnRybkN1MnhQbkpBVHpucnoxRUpIR3h6Ni1ONzB4aF82Z1FkVV9LNkl2VUd6Zm94WV9XSUZSd2VwVXZJLUNkb0FkY1l1VHItaW0zbnYtZFFFeC5DQkVnem5ieWpjVDlTeUl5alBUNkNmZWk2NWVydU1jU1lhQlZJS1daYTlkLXh5dkExdDdJWE5fdGNKSVQxVURWd3lJbUFPNEZTMlhDTWc1Z1VPa1pBUQ==">
<input type="hidden" name="&#95;eventId" value="submit">
<input type="hidden" name="geolocation" value="">
<input type="submit" value="Submit request">
</form>

Besides the CSRF issue, I also wonder why the same Spring Webflow execution ID can be used several times. Shouldn't the execution ID be deleted after reaching an end state of the flow?

Cheers,

  Paul

[Carl Waldbieser]

Technically, that is not CSRF, but I understand the concern you have-- phisher captures the username/password on their own form, and then sends the credentials on to the legitimate site so the user is none the wiser.

A nonce in this case wouldn't buy you too much if the user doesn't notice they are at the wrong site.  Consider the attacker could just POST to her own site then redirect to the real site, leaving the user thinking she just entered a typo in the username or password.  Or the phisher could be proxying the site, maybe using something like an sslstrip attack.  In all those cases, if the user hasn't noticed she wound up on https://evil-site-that-looks-like-your.net/ she may be fooled into giving up her credentials.

A nonce is useful as CSRF protection in cases where you are already authenticated to a site, so a bad actor can't trick you into doing something that would normally require authentication.

Historically, I believe CAS used to have a "login ticket" which was a nonce.  It dropped it somewhere between 3.x and 5.x, I believe.

Thanks,

Carl Waldbieser

ITS

Lafayette College

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/822b9c4b-dfdd-4943-b40c-a99c890513e5n%40apereo.org.

[Paul Roemer]

Hey Carl,

you are right. The problem described is not a CSRF issue. Still, I wonder if users of CAS are aware of it. In the end it means that attackers can easily trigger any flow provided by CAS, right? That bugs me.

Before, I was under the assumption that the Webflow execution ID was used as nonce. But I was wrong as it can be reused even if the flow succeeded already...

[Ray Bon]

Paul,

All log in systems would suffer from this same problem. Since the secured phase of the session has not yet begun, there is no way to  protect the user (save the limited case of ip/machine verification with intranet only log in - must be rare these days).

The fake site could run a script on the back end that connects to the legitimate log in screen and scrapes the form details, then feeds those to the user's browser.

The protection against this is user education; Before entering your username and passphrase, verify the site is legitimate.

'Log in with a new device' alerts may provide a clue to the user, but would require user education to be effective.

A second factor will go a long way in preventing compromised credentials from being used by a bad actor.

Ray

On Thu, 2021-04-22 at 09:12 -0700, Paul Roemer wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@uvic.ca

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.