CVE-2023-45857 (CWE-359) XSRF-TOKEN value is disclosed to an unauthorised actor

[valentin-panov]

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

1. 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
2. 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,
  });

3. 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",
    });

4. 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));

5. Run your project, and open the browser's network tab for debugging and monitoring network activity.
6. Verify that the cross-domain request to "https://www.com/" includes the "X-XSRF-TOKEN" header with the value "whatever."
7. 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

[tiagojufr]

@valentin-panov does this vuln only affect 1.5.1 and no other versions? Dependency track is showing me this vuln for 1.1.3 (I guess it is associating this vuln to all versions of axios).
Edit: last time the logic in the affected line changed was in this commit, so I guess this affects a lot of versions looking at the tags list that commit is part of.

[valentin-panov]

@valentin-panov does this vuln only affect 1.5.1 and no other versions? Dependency track is showing me this vuln for 1.1.3 (I guess it is associating this vuln to all versions of axios). Edit: last time the logic in the affected line changed was in this commit, so I guess this affects a lot of versions looking at the tags list that commit is part of.

I agree with you, and the problem may have affected all versions released since then.

[valentin-panov]

Cannot reproduce on the fresh machine and fresh project. Close the issue, researching the reproducible env.

[valentin-panov]

I reproduced the defect in a new project with the latest package versions and updated the description.

[304NotModified]

@valentin-panov what are ER and AR?

[valentin-panov]

@valentin-panov what are ER and AR?

Expected result
Actual result

[mschaefer-gresham]

Does this only apply to scenarios where the XSRF-TOKEN cookie is created in the front-end as shown above? In my case the XSRF-TOKEN cookie is created and managed by the server and I can't reproduce. Using version 1.5.1.

[valentin-panov]

Does this only apply to scenarios where the XSRF-TOKEN cookie is created in the front-end as shown above? In my case the XSRF-TOKEN cookie is created and managed by the server and I can't reproduce. Using version 1.5.1.

I don't think the cookie's origin is a critical factor. In my opinion, what really matters is whether the cookie is accessible to client-side JavaScript and if the 'withCredentials' attribute is set to 'true.'

[kraison1]

I encountered this problem in Blackduck. Is this the same problem?

[valentin-panov]

I encountered this problem in Blackduck. Is this the same problem?

Not quite sure. There are no refs on your screenshot. It may be something else.

[valentin-panov]

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

[kraison1]

I encountered this problem in Blackduck. Is this the same problem?

Not quite sure. There are no refs on your screenshot. It may be something else.

I think these pictures might be of the same problem

[valentin-panov]

I encountered this problem in Blackduck. Is this the same problem?

Not quite sure. There are no refs on your screenshot. It may be something else.

I think these pictures might be of the same problem

The description appears to be identical to issue #6022. However, the author of the issue has not supplied any specific details. I'm assuming that this issue may be the same.

[herarya]

any update for this, snyk also report same issue

https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459

[valentin-panov]

any update for this, snyk also report same issue

https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459

Regrettably, no, I haven't received a response from the team through this platform or via email.

[charlieoliver]

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

@herarya does the above correct the Snyk finding?

[blee-teckcraft]

We are also facing this issue reported by SNYK. Any updates would be much appreciated!

[seanputera]

Same here from Snyk. Thanks for looking into this!

[herarya]

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

@herarya does the above correct the Snyk finding?

yes correct, now blocked our ci/cd.

[syukronarie]

To Reproduce

1. 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
2. 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,
  });

3. 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",
    });

Is the Axios CSRF vulnerability a false positive for users who do not have the withCredentials property activated?
Under what conditions is the Axios CSRF vulnerability a false positive?

[Bam6ycha]

Hi guys! Any plans to fix this vulnerability for 0.x versions?

1.0 had been released more than a year ago. Maybe just update?

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.

[304NotModified]

Hi guys! Any plans to fix this vulnerability for 0.x versions?

1.0 had been released more than a year ago. Maybe just update?

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.

The security support of NodeJS 10 ended 2.5 years ago? (30 Apr 2021, see https://endoflife.date/nodejs)

[theta682]

Hi guys! Any plans to fix this vulnerability for 0.x versions?

1.0 had been released more than a year ago. Maybe just update?

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.

users with NodeJS 10 don't need security updates for axios because NodeJS is a bit heap of security vulnerabilities

[marcusdelang]

Hi guys! Any plans to fix this vulnerability for 0.x versions?

1.0 had been released more than a year ago. Maybe just update?

0.x -> 1.0 has breaking changes preventing updating if you rely on those features: #5365

Don't know if they plan to fix that or if there is an alternative solution to that problem.

[AmsterGet]

Hi guys!
Thank you for your helpful comments.
Let me describe our case.
In a nutshell, we can't just upgrade to the latest version of axios right now, as that would break our reporters running in a Node.js 10 environment.
Yes, we know it's an outdated version of the engine, but our stats say it's still being used by our users with ~7k runs per month.
So this update should be made in the next major version of our library, which will drop support for Node.js 10.
At the moment we are sticking to the correlation between client libraries and server versions, so we need to discuss this approach internally to change it or find another solution.

If you have any useful insights that can help us solve this problem without changing the current versioning approach, it would be greatly appreciated.

[xfournet]

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?

[304NotModified]

0.x -> 1.0 has breaking changes preventing updating if you rely on those features: #5365

Ok, I'm a bit shocked that this bug, which have several open PRs, still isn't fixed.

[ialexryan]

@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!

[suprajasutti]

I am looking into this issue and I want to know if this is only an issue in scenarios where the third party application/URL is connected to the application using this token?