CVE 2023 45857

[valentin-panov]

Hi @jasonsaayman,

This pull request is related to an issue #6006

Could you review it?

Kind regards,
Valentin

⚠️ Critical vulnerability fix. See https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459

[jasonsaayman]

looks good thanks 🙌

[emzeidan]

@valentin-panov Hi! It looks like we have some tests failing in the CI Actions because of the removal of config.withCredentials.
Failing spec: @test/specs/xsrf.spec.js#'should not set xsrf header for cross origin when using withCredentials'

Chrome Headless 118.0.5993.88 (Linux x86_64) xsrf should set xsrf header for cross origin when using withCredentials FAILED
	Expected undefined to equal '12345'.

Firefox 119.0 (Ubuntu 0.0.0) xsrf should set xsrf header for cross origin when using withCredentials FAILED
	Expected undefined to equal '12345'.

Suggested edit:

// update test name to match behavior
 it('should not set xsrf header for cross origin when using withCredentials', function (done) {
    document.cookie = axios.defaults.xsrfCookieName + '=12345';

    axios('http://example.com/', {
      withCredentials: true
    });

    getAjaxRequest().then(function (request) {
      // update expect() to match behavior
      expect(request.requestHeaders[axios.defaults.xsrfHeaderName]).toEqual(undefined);
      done();
    });

[valentin-panov]

@valentin-panov Hi! It looks like we have some tests failing in the CI Actions because of the removal of config.withCredentials. Failing spec: @test/specs/xsrf.spec.js:78:69

Hi, thank you. Will add it today.

[jerell-mendoza]

Thanks @valentin-panov for addressing this vulnerability. My team using Axios thanks you.

[emzeidan]

Thank you!

[trailfox]

I've just tried upgrading to axios v1.6.0 and then run snyk test to see if CVE-2023-45857 has been remediated. However Snyk is reporting that axios v1.6.0 still has the vulnerability

Issues with no direct upgrade or patch: ✗ Cross-site Request Forgery (CSRF) [High Severity][https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459] in axios@1.6.0 introduced by axios@1.6.0 No upgrade or patch available

Has anyone else tried this and are they seeing anything different.

[Turbotailz]

I've just tried upgrading to axios v1.6.0 and then run snyk test to see if CVE-2023-45857 has been remediated. However Snyk is reporting that axios v1.6.0 still has the vulnerability

Issues with no direct upgrade or patch: ✗ Cross-site Request Forgery (CSRF) [High Severity][https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459] in axios@1.6.0 introduced by axios@1.6.0 No upgrade or patch available

Has anyone else tried this and are they seeing anything different.

Most likely because Snyk hasn't yet updated so any versions >=0.8.1 will be affected until they add in the fix version.

[herarya]

Thank you very much

[CleverCoder]

This is a breaking change. Should force a major version bump. Here's why:

• I send CSRF token as a cookie, with samesite lax, for domain ".domain.com"
• Just as an example, there's a "frontend.domain.com" and a "backend.domain.com".
• The header is no longer being sent to backend.domain.com, but the cookie is (as it matches .domain.com)
  Projects might update to this version and suddenly API calls start to fail, and the reason isn't obvious.
  The solution I have is to set it in our interceptor now.

[louis-l]

Same issue, my app failed after updated to v1.6.0
Had to downgrade to v1.5.1

[xHeaven]

Pretty much the same scenario here as above, I just had to roll back all my sites to 1.5.1 and fix the package version there.

• Our frontends are set up on domain.com, sending out the CSRF token as a cookie with SameSite=Lax for .domain.com.
• Backends are at api.domain.com. The XSRF token header isn't being sent anymore, which is causing CSRF token mismatch errors.

Honestly, feels like a breaking change to me. Probably would've made more sense to tag it 2.0.0.

@jasonsaayman Is there anything we can do about this?

---

Something like this would solve the issue for this usecase, however, this is not exactly the "isURLSameOrigin" functionality, and also lacks support of edge cases, such as .co.uk domains. psl could handle this part though.
Anyway, this is what I implemented in my private fork, because I know that I won't use such TLDs so it's good enough for me.

// lib/helpers/isURLSameOrigin.js
/**
 * Extract the main domain from the given hostname.
 * @param {String} hostname The hostname from which to extract the main domain
 * @returns {String} The main domain extracted from the hostname
 */
function getMainDomain(hostname) {
  if (typeof hostname !== 'string' || hostname.length === 0) {
    return '';
  }

  // Handle IP addresses
  const ipPattern = /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/;
  if (ipPattern.test(hostname)) {
    return hostname;
  }

  const parts = hostname.split('.');

  // Handle localhost and internal domains
  if (parts.length === 1) {
    return hostname;
  }

  const [domain, tld] = parts.slice(-2);

  return `${domain}.${tld}`;
}

return function isURLSameOrigin(requestURL) {
  const parsed = (utils.isString(requestURL)) ? resolveURL(requestURL) : requestURL;
  return (parsed.protocol === originURL.protocol &&
-     parsed.host === originURL.host);
+     getMainDomain(parsed.hostname) === getMainDomain(originURL.hostname));
};

[valentin-panov]

@CleverCoder , @louis-l , @xHeaven
I believe we need an option to determine trusted hosts to which axios should send the csrf token in headers.
While this option has not appeared, we can use an interceptor.