OWASP CSRFGuard is vulnerable to CVE-2021-28490

[PetRay]

We make use of CSRFGuard version 4.0.0 in our applications but security scanning tools are reporting it is vulnerable to the following High severity CVE:

https://nvd.nist.gov/vuln/detail/CVE-2021-28490

With a score of 8.8 this looks like something that would need to be investigated/fixed or is there any good workaround or mitigation for this issue that you can recommend?

[forgedhallpass]

To be honest I wasn't aware of this CVE, I wonder where it has been reported, but in any case, I don't agree with the severity. Will try to get in touch with the person who reported it, but just to clarify some things:

"In OWASP CSRFGuard through 3.1.0, CSRF can occur because the CSRF cookie may be retrieved by using only a session token."

• CSRFGuard uses headers, hence there is no CSRF cookie to be retrieved.
• You can use token-per-page with token rotation, which would assign unique, single-use tokens for each secured page.
• There is also the possibility to validate referer headers

That being said, in order to bypass these validations, you would need to have a severe XSS vulnerability within your application and probably incorrect CSP/CORS rules in order to exploit this, in which case you have bigger problems than CSRF. Not having XSS vulnerabilities is a prerequisite for every CSRF protection (that I know).

[forgedhallpass]

Quoting from the OWASP CSRF Prevention Cheat Sheet:

"Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!
See the OWASP XSS Prevention Cheat Sheet for detailed guidance on how to prevent XSS flaws."

[reidmefirst]

Hi Ray -

We verified with a vendor that uses CSRFGuard that it is in fact vulnerable. Exploiting does not require that your application has any XSS -- just visiting a malicious page in another browser tab is enough to exploit the issue. This scenario does require that a victim is 1) logged in to your application and 2) is visiting a malicious page which can be hosted on an entirely different webserver.

If you'd like a working proof of concept exploit for your application, I'd be happy to build you one (poc must be tailored to your application unfortunately -- what URL actually serves up the CSRFGuard token may be configured by you and an exploit must know what that URL is). Please reach out if you're interested.

Reid

[aramrami]

Hello,
Please build a PoC showing how to exploit this vulnerability with the version 4.0.0 only. We will do our best to correct it if the last release is also vulnerable.

In the following link https://github.com/reidmefirst/vuln-disclosure/blob/main/2021-01.txt the author wrote this:
"A lot of old web applications don't support the pre-flight checks required, and so will only work with an ancient web browser. OWASP developers did acknowledge the problem but have refused to release any advisory to warn users about the issue and has not committed to a fix."

That's not true. He never contact me or inform me via GitHub.
Saying something wrong about OWASP is really not good.

[forgedhallpass]

@reidmefirst

The test application within this repository can be used for demonstrating your PoC. I've added a /counter endpoint that returns the value of the counter if invoked with a GET request, and enables incrementing the value by sending a POST request (see counter.html)

Steps for building the application: https://github.com/OWASP/www-project-csrfguard#building-the-code
For your convenience, I've also pre-built a WAR for you: https://github.com/OWASP/www-project-csrfguard/releases/download/4.0.1/csrfguard-test-jsp-4.0.2-SNAPSHOT.war

Note:

• Please make sure that you deploy the test application on your machine, and access it through http://localhost:8080, because the referer pattern is configured against that address. Optionally you can rewrite this value, by modifying the org.owasp.csrfguard.JavascriptServlet.refererPattern property in the Owasp.CsrfGuard.overlay.properties file, inside the WAR.
• When executing the attack, please make sure you deploy your exploit code to a different domain. You can simulate this by adding a new entry in your hosts file (e.g. 127.0.01 attacker.local) and execute your PoC.html through http://attacker.local/PoC.html

If you manage to manipulate the counter value outside localhost, then the attack is considered successful.

Thanks.

[prashantkadam12]

Hello @forgedhallpass

How can I check exploitability for my webapp, general guidelines to exploit would help to see if my app is safe or not from this vulnerability ..

[forgedhallpass]

Hello @prashantkadam12,

I don't think there is a vulnerability. I've provided the steps for @reidmefirst above so that he can also do his testing, and then we'll see whether there is an issue or not.

[prashantkadam12]

Hello @forgedhallpass

Any further updates on this ? Have we concluded on whether this is a vulnerability (for both versions 3.1.0 / 4.0) ? Is it exploitable in real-world ? Will upgrading to 4.0 would safeguard application for this vulnerability ?

[forgedhallpass]

Hello @prashantkadam12

I will be providing a detailed description sometime in the future, but in short, an attack is only possible if there are multiple misconfigurations in place, combined with social engineering.

E.g. if the user is tricked to download an HTML file, uses Internet Explorer, disregards the warning about running executable content, is logged into the target application in the same browser and the application is deployed on his machine OR the application has unsafe CORS configuration or CORS is enabled from the browser via (mis)configuration. Even this way if CSRF Guard is correctly configured, writing an exploit is not trivial to write by far.

At the end I believe the probability for all these stars (and not just) to align, reduces the overall severity to LOW. Besides, using browsers with insecure configuration and exploitation with social engineering is not a vulnerability in CSRF Guard.

[Alexander-Shevchenko]

Hello @forgedhallpass , do you still plan to provide a detailed description please?
That's still rated as High at National Vulnerability DB as per PetRay's link above 😥

[forgedhallpass]

@Alexander-Shevchenko will do when I'll have enough time. The short version you can see above. The CVE's severity rating is not correctly assessed (bloated). You can find other sites (e.g. https://security.snyk.io/vuln/SNYK-JAVA-ORGOWASP-1912877, https://vuldb.com/?id.181209) where the same CVE has Low or Medium (but even the Medium is an overstatement) severity.

In the meantime I've released, the 4.1.1 version which contains a bugfix related to an additional security measure (see
#38)

[forgedhallpass]

Even though, (as previously mentioned) this is a very special corner-case scenario with a LOW severity, I've modified the default behavior of CSRFGuard not to serve content to Internet Explorer by default anymore.

See #101 for reference.