02-25-2021 06:28 AM
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
06-09-2022 02:34 AM
The above work around worked for this environment but was determined to be a Cisco Bug that has since been resolved by updating to the latest FXOS and FTD Version 7.0.1.1. We also found that the exact same error message occurs if you are using User Certificate Authentication in SAML on Microsoft ADFS, but the Certificate is using Elliptical Curve (Which you would think you would want as more secure). Create with RSA and the problem goes away in this case it is MS ADFS that has the problem just the error message not that helpful makes you think same issue
Thought would add this so we have a list of possibilities that give the same error message and possible solutions
06-09-2022 01:48 AM
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.
07-06-2023 01:05 AM
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
07-06-2023 01:10 AM
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
07-06-2023 01:34 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide