axios: CVE-2023-45857 (CWE-359) XSRF-TOKEN value is disclosed to an unauthorised actor
Describe the bug
Hi team, @jasonsaayman and @DigitalBrainJS,
The library inserts the X-XSRF-TOKEN header using the secret XSRF-TOKEN cookie value in all requests to any server when the XSRF-TOKEN cookie is available, and the withCredentials setting is turned on. If a malicious user manages to obtain this value, it can potentially lead to the XSRF defence mechanism bypass.
It’s crucial to ensure the protection of CSRF tokens. These tokens should be treated as confidential information and managed securely at all times. You may check it here: https://portswigger.net/web-security/csrf/preventing https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
Type of vulnerability: CWE-359: Exposure of Private Personal Information to an Unauthorized Actor Severity: High (7.1) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
To Reproduce
- Start a new project using the latest version of Next.js by running the following command:
npx create-next-app@latest. Then, install the latest version of the Axios library with this command:npm i axios - Create an Axios instance with the following configuration, which enables cross-site request forgery (CSRF) protection by including credentials in requests:
const instance = axios.create({
withCredentials: true,
});
- Install the XSRF-TOKEN cookie with specific attributes. Set the cookie value “whatever” and configuring it for the “localhost” domain with strict same-site policy:
const cookies = new Cookies();
cookies.set("XSRF-TOKEN", "whatever", {
domain: "localhost",
sameSite: "strict",
});
- Initiate a cross-domain request using your Axios instance. In this example, we’re making a GET request to “https://www.com/,” and we handle the response and potential errors:
instance
.get("https://www.com")
.then((res) => console.log(res.data))
.catch((err) => console.error(err.message));
- Run your project, and open the browser’s network tab for debugging and monitoring network activity.
- Verify that the cross-domain request to “https://www.com/” includes the “X-XSRF-TOKEN” header with the value “whatever.”
- Confirm that the “XSRF-TOKEN” cookie’s value is disclosed to any 3rd-party host when making requests using the Axios instance. This is essential for security as you don’t want to leak CSRF tokens to unauthorized entities.
Code snippet
lib/adapters/xhr.js:191
const xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath))
Expected behavior
ER: the XSRF-TOKEN is not disclosed to a 3rd party host AR: the XSRF-TOKEN is disclosed in every request made with the Axios instance
Axios Version
[v0.8.1] - [v1.5.1]
Adapter Version
No response
Browser
No response
Browser Version
No response
Node.js Version
No response
OS
No response
Additional Library Versions
No response
Additional context/Screenshots
The current effective solution is to change the default XSRF-TOKEN cookie name in the Axios configuration and manually include the corresponding header only in the specific places where it’s necessary.
https://nvd.nist.gov/vuln/detail/CVE-2023-45857
https://prnt.sc/xDcRmFozxSHJ
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Reactions: 21
- Comments: 40 (10 by maintainers)
Links to this issue
Commits related to this issue
- Update axios https://github.com/axios/axios/issues/6006 — committed to CybozuDocs/hugo-template by chick-p 8 months ago
Hi guys! Any plans to fix this vulnerability for 0.x versions?
Regrettably, no, I haven’t received a response from the team through this platform or via email.
Basically your are asking for the Axios maintainers to compensate the lazyness/negligence/incompentency (choose the one you prefer) of your customers for free. Think about software companies that charging high price to offer extended support their EOL software.
Moving forward, if you can’t get your customers to upgrade, click the Fork button and backport the fix yourself. After all, it is to have this freedom that we use open source?
Expected result Actual result
I reproduced the defect in a new project with the latest package versions and updated the description.
@valentin-panov The CVE-2023-45857 is still marked as Reserved. As the author of this issue/fix, do you have any insight into what’s preventing it from being published? Or should we contact cve@mitre.org directly?
Edit: It is now published, awaiting NVD analysis. Thanks.
@valentin-panov Thx for the report and fix! Released in v1.6.0
1.0 had been released more than a year ago. Maybe just update?
@herarya does the above correct the Snyk finding?
any update for this, snyk also report same issue
https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459
0.x -> 1.0 has breaking changes preventing updating if you rely on those features: https://github.com/axios/axios/issues/5365
Don’t know if they plan to fix that or if there is an alternative solution to that problem.
The security support of NodeJS 10 ended 2.5 years ago? (30 Apr 2021, see https://endoflife.date/nodejs)
By the way, the current effective solution is to change the default XSRF-TOKEN cookie name in the Axios configuration and manually include the corresponding header only in the specific places where it’s necessary
@valentin-panov what are ER and AR?
@marcusdelang @304NotModified and others who were blocked on upgrading to v1.x.x by this bug, I have good news – the fix was just merged and released as v1.6.6!
users with NodeJS 10 don’t need security updates for axios because NodeJS is a bit heap of security vulnerabilities
Unfortunately, we can’t just update because we are developing an opensource solution, and some of our users are still using NodeJS 10. And we have to support it as well. But axios 1.6 doesn’t work with NodeJS 10.
It’s given as a work-around on Snyk
Looks like so.
Is the Axios CSRF vulnerability a false positive for users who do not have the
withCredentialsproperty activated? Under what conditions is the Axios CSRF vulnerability a false positive?