CSCvw59876 - ASA "Potential CSRF attack detected." when SAML assertion validation fails

[aleksta9826435]

Hi!

I have been encountered the following message "Potential CSRF attack detected". I've tried to reconfigure the SAML within the ASA, but It doesn't help. I'm using the AnyConnect software and everything seems to be working fine when I'm authenticating but It's like the last step it fails on which is frustrating. 

My ASA version is 9.15. Is there any workaround to fix this issue? 

Best regards
Aleksander Stanojevic

[js369716]

No fixed version and no workaround yet but:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw59876

[Ondrej_]

Hi,

I see that 10 people had this problem according to the OP "likes", as of now there is 32 support cases for CSCvW59876 (was actually 29 two days ago), so I guess this is still not fixed.

Please, anyone care to share some details - at least the SAML provider? We have this issue with Azure AD, but not for instance with DUO Access Gateway (FTD 6.7)...

Thanks

Kind regards
Ondrej K.

[Matthew24100]

Has anyone had any success solving this problem?

[ChrisCarter1186]

FTD 6.7 with Azure same problem. 

 

[rasmusan1]

Hi,

I had the same issue, and managed to solve it - It seems that Azure is sometimes presents the wrongs certificate under SAML config (I think this happens if you download certificate just after creating Enterprise Application) - the correct certificate should have a CN of "Microsoft Azure Federated SSO Certificate", and a start date of the day of creation of the Enterprise Application... So check your SAML certificate from Azure, re-download/import and try again

So I guess there is sometimes a little delay in the creation of SAML certificate on Azure side - and instead of throwing an error when trying to download certicate when this is not ready, they just give you some other certificate (not sure what that is)...

At least this was the issue in my case - got this confirmed by Cisco TAC as well, that they have seen this behaviour multiple times with Azure involved...

Hope this can help others struggling with same issue !

/Rasmus

[ChrisCarter1186]

Rasmus 

That was the solution, grabbed the correct certificate and it has solved the issue. THANKS!!!

[ctohang99]

Hello, Checked the Azure Certificate and confirmed "Date and CN".

Unfortunately, the AnyConnect from FTD still facing the same error.

May I have more detail?

thanks!

[jack.chen.job]

I had the same problem today, moved a working Cisco anyconnect VPN to a different tenant and got this error. Yes the initial SAML certificate is a weird one and it doesn't work.

@ctohang99  , after I switched to the correct certificate, it also didn't immediately work. I had to change the connection profile -> SAML identity Provider to None, then change it back, then it worked, You can give it a try.

[phil.jackson@ai-solutions.com]

Do you have multiple profiles setup for your VPN? Mine only works for one profile, but I have 5 profiles setup. And Azure doesnt give unique entity IDs for each application so I am completely stuck.

[jack.chen.job]

I have two profiles, but one of them is LDAP.  So you have 5 profiles in same ASA configured with same Azure AD? I would think it shouldn't be a problem.  In each Azure application, you will configure different SP identifier :

https://vpn.yourasa.com/saml/sp/metadata/differentProfilename

And in each profile, you should choose the correct SAML certificate.

[jack.chen.job]

phil.jackson@ai-solutions.com  did you get multiple profiles working ?

I guess maybe you didn't configure reply URL ( ACS URL) in Azure properly.

The  help shows "Patterns: https://YOUR_CISCO_ANYCONNECT_FQDN/+CSCOE+/SAML/SP/ACS" 

But it should be https://YOUR_CISCO_ANYCONNECT_FQDN/+CSCOE+/SAML/SP/ACS?tgname=TunnelGroupName , then you can have multiple tunnel groups.

[phil.jackson@ai-solutions.com]

Thank you!!! I have been racking my brain for months trying to figure this out.

[fturner94]

I also had this problem and the directions in the Cisco documentation here (https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215935-configure-asa-anyconnect-vpn-with-micros.html_) are part of the problem. Everything up to the downloading of the certificate is solid otherwise.

When you're setting this up, pay particular attention to the download certificate portion. The ASA generally likes things to be in .pem format when uploading certificate files but the default option to download the certificate from Azure is actually in Base64 format.

The step they left out in that documentation that would save you having to re-add the cert (Which means you're going to have to un-apply it from your VPN profile and also un-apply it from the SAML Idp, save, re-import, re-apply, test again) is if you just clicked on the "Edit" button on that section (SAML Signing Certificate) as you're stepping through the Azure configuration and it will give you the option to download the correctly formatted cert (.pem).

Hope this helps some others with the additional elaboration as to why that Base64 download does not work. Cisco, please update this documentation!!

[phil.jackson@ai-solutions.com]

I tried this and still having issues. It might be how I have it setup. Does anyone have multiple profiles setup using this? Since, Azure only does one entity ID for everything, unlike Okta, which is a unique web link, I have to bunch everything up together. It seems that I can only get one profile to properly login, but everything else gets the cross scripting error. I am regretting moving away from Okta now LOL.