2021-01.txt

Date: 06-August-2021
Updated: 13-September-2021
Vendor: Open Web Application Security Project (OWASP)
Product: CSRFGuard
Versions affected: 3.0, 3.1.0, 4.0 pre-release. Other versions may also be affected.
Product URL: https://owasp.org/www-project-csrfguard/ 

Summary:

OWASP CSRFGuard project is vulnerable to CSRF (CVE-2021-28490), (CWE-352), (CVSS3.1 score: 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)). 

Note that the CVSS score takes the liberty of assuming that your web application has something worth confidentiality-ing, integrity-ing, or availability-ing. What an attacker can actually do will depend upon who they trick into clicking a link.

Description:

CSRFGuard is a project meant to add CSRF protection to java-based web applications. Unfortunately versions 3.0, 3.1.0 and including pre-release versions of 4.0 are vulnerable to CSRF. The CSRF cookie may be retrieved using only a session token, which may be wrapped by a third-party request and which a browser may happily provide.

Modern browsers that do fancy pre-flight checking may stop the attack, but this depends upon the configuration of your web application. A lot of old web applications don't support the pre-flight checks required, and so will only work with an ancient web browser. *Update*: In particular, your browser MUST support CORS and MUST deny cross-origin requests to the protected application. With this protection, CSRFGuard 4.0.0 will work as intended. Without this protection, CSRFGuard may fail.*/Update*

*Update*: OWASP developers did work with me and give an opportunity to show how the issue is a problem. We disagree on the real-world exploitability of the issue, since exploitation requires a browser that will make cross-origin requests from a malicious domain (or, an attacker tricks an end user into downloading and opening a .html file in the same browser that they are currently logged-in to the current web application with). Anyway, it is all splitting hairs and typical vulnerability reporting stuff: as above, if you are using CSRFGuard make sure all your clients respect CORS!*/Update*

Determining if your application is vulnerable: 

Developers: Look to see if you include the csrfguard project in your java application. If you are using any version (including 4.0), you are most likely vulnerable. 

End users: Some versions of CSRFGuard will set a special header "X-Protected-With: OWASP CSRFGuard Project" within the web application, although this is configurable by the user. Look at HTTP headers for the page you are visiting to see if there is any reference to CSRFguard headers.

Researchers: If you use a tool like Burp, look for CSRFGuard text in your web browser history.

FAQ:

CSRF? In 2021?

Yeah, no, it's not very interesting. Please don't think that's some amazing bug. In spite of the high CVSS score it's pretty lame.

How do I exploit this?

You'll have to send a request to your web application's csrf token request point. No, I won't show you how to do that on your app. Hire a web pentester, they'll teach you how.

In the grand scheme of things how bad this?

On the technical side of things, it really isn't that big of a deal. Most web applications have terrible security anyway, and if you are vulnerable to this, then you probably also have some nastier bugs that are infinitely more useful to an adversary. 

*Update*: The CSRFGuard devs did reach out and look into the issue once an advisory was made public. While we disagree with the final exploitability, that is a good step. Now if OWASP would have some standard disclosure process rather than relying on individual researchers and individual developers to butt heads about exploitation, that would be swell...

But hey, you get what you pay for, and the software is free.

"You get what you pay for"? I didn't pay for this advisory and it's useless to me!

🤔. That's not a question. But I guess I see your point?