cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
34724
Views
62
Helpful
33
Replies

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

aleksta9826435
Level 1
Level 1

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

33 Replies 33

songs
Level 1
Level 1

Hi Everyone, 

 

I just had this problem too and have resolved it - When you get the "potential CSRF detected" when you try to connect. This means your EntityID url is incorrect. so you need to make sure that you copy the exact EntityID url from the xml which is enclosed in double quotes.

 

that will make the problem go away.

JohnKimble
Level 1
Level 1

Hi Aleksta
I know this is an old post, but after confirming all my URLs were correct, I resolved the issue by removing the default value of 300ms in Request Timeout, under Single Sign-On server profile. Removing the 300ms, sets Timeout to "Use the timeout set by the Provider". Everything works great now. You can read more about it under "SAML Timeout section" here https://www.cisco.com/c/en/us/td/docs/security/asa/asa916/asdm716/vpn/asdm-716-vpn-config/webvpn-configure-users.html

JohnKimble
Level 1
Level 1

Hi
I know this is an old post, but for anyone who still have this issue, here is what I did. After confirming all my URLs were correct, I resolved the issue by removing the default value of 300ms in Request Timeout, under Single Sign-On server profile. Removing the 300ms, sets Timeout to "Use the timeout set by the Provider". Everything works great now. You can read more about it under "SAML Timeout section" here https://www.cisco.com/c/en/us/td/docs/security/asa/asa916/asdm716/vpn/asdm-716-vpn-config/webvpn-configure-users.html

Worth checking. In our case this was the default, the problem was caused by a bug since resolved by Cisco while the time was in sync (By NTP) in the virtual container instance it was not syncing in another place but should of (sorry can't remember were). My previous original post was only useful for a temporary fix as it kept drifting 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: