Server-Side Request Forgery Vulnerability (CVE-2024-39338)

[jeffhacks]

Describe the bug

Axios is vulnerable to a Server-Side Request Forgery attack caused by unexpected behaviour where requests for path relative URLS gets processed as protocol relative URLs.

This could be leveraged by an attacker to perform arbitrary requests from the server, potentially accessing internal systems or exfiltrating sensitive data.

To Reproduce

In this vulnerable code snippet, the developer intended to invoke a path relative to the base URL, however it allows an attacker to craft a malicious protocol-relative URL which is then requested by the server. Given protocol-relative URLs are not relevant server-side as there is no protocol to be relative to, the expected result would be an error. Instead, a valid URL is produced and requested.

Example Vulnerable Code

const axios = require('axios');

this.axios = axios.create({
  baseURL: 'https://userapi.example.com',
});

//userId = '12345';
userId = '/google.com'

this.axios.get(`/${userId}`).then(function (response) {
  console.log(`config.baseURL:  ${response.config.baseURL}`);
  console.log(`config.method:   ${response.config.method}`);
  console.log(`config.url:      ${response.config.url}`);
  console.log(`res.responseUrl: ${response.request.res.responseUrl}`);
});

Expected Output (Prior to axios 1.3.2):

(node:10243) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_URL]: Invalid URL: //example.org

Developer might also have expected:

config.baseURL:  https://userapi.example.com
config.method:   get
config.url:      https://userapi.example.com//www.google.com/
res.responseUrl: https://userapi.example.com//www.google.com/

Observed Output:

config.baseURL:  https://userapi.example.com
config.method:   get
config.url:      //google.com
res.responseUrl: http://www.google.com/

This behaviour is potentially unexpected and introduces the potential for attackers to request URLs on arbitrary hosts other than the host in the base URL.

The code related to parsing and preparing the URL for server-side requests, prior to version 1.3.2, only passed one argument to the Node.js URL class.

    const fullPath = buildFullPath(config.baseURL, config.url);
    const parsed = new URL(fullPath);
    const protocol = parsed.protocol || supportedProtocols[0];

Version 1.3.2 introduced http://localhost as a base URL for relative paths (#5458)

    const fullPath = buildFullPath(config.baseURL, config.url);
    const parsed = new URL(fullPath, 'http://localhost');
    const protocol = parsed.protocol || supportedProtocols[0];

As protocol-relative URLs are considered to be absolute, the config.baseURL value is ignored so protocol-relative URLs are passed to the URL class without a protocol. The node.js URL class will then prepend the protocol from 'http://localhost' to the protocol-relative URL.

For example

> new URL('//google.com', 'https://example.org');
URL {
  href: 'https://google.com/',
  ...
}

> new URL('//google.com', 'file://example.org');
URL {
  href: 'file://google.com/',
  ...
}

Code snippet

No response

Expected behavior

An error could be raised when attempting to request protocol-relative URLs server-side as unlike in a client-side browser session, there is no established protocol to be relative to.

Axios Version

No response

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

No response

[pinussilvestrus]

Is there a fix plan for this? v1.7.3 is not fixing this and it's blocking releasing one of our libraries.

[SilverSting]

Hi. Trying to understand this vulnerability better.

Mixed use of relative and absolute (including, protocol-relative) URLs

Axios will see //google.com as an argument to get call, since the text substitution will occur outside of the function call and that's an acceptable value, isn't it? It's quite possible that the same client instance could be used for fetching both relative URL and absolute URL based resources.

userId = '/google.com'
this.axios.get(`/${userId}`);

Of course this may not align with application developer's expectation (ie. to be relative path). But it feels like that's not Axios' problem to solve. Axios could potentially warn this use pattern (ie. use of baseUrl with non relative path), but it seems too harsh for axios to dictate this.

Impact of using protocol-relative URLs

The following code kinda forces http protocol if protocol-relative URLs are used.

const parsed = new URL(fullPath, 'http://localhost');

Is this the main concern here? I guess an attacker could potentially move away from non-http protocol (eg. local file location, deemed safe) to http protocol to deliver remotely located malicious files into the target system.

Expected behavior

An error could be raised when attempting to request protocol-relative URLs server-side as unlike in a client-side browser session, there is no established protocol to be relative to.

If this is indeed a good solution, then isAbsoluteURL could be updated to ignore protocol-relative URLs to produce this output. Please note config.url is set by the _request implementation,, so it will be still //google.com. But requested url will be combined url.

config.baseURL:  https://userapi.example.com
config.method:   get
config.url:      //google.com
res.responseUrl: https://userapi.example.com//google.com

[hainenber]

Guess most of us are here due to Snyk's action lately ;)
... Well, the enterprise-y us.

I made a draft PR to materialize @SilverSting's idea above. Do lmk if that works out in the long-term, fellas

Edit: regression test added

[nathanloyer]

Several auditing tools are reporting this issue as of today, including npm audit.

GHSA-8hc4-vh64-cxmj

[furkanmustafa]

This vuln report seems like alerting.. all the alerts.. But I'm quite confused (maybe not enough caffeine today)

Question: "using unsanitized input/data as string in URLs" made towards elsewhere is insanely dangerous in any way? on any library any place and any location. I somehow cannot thing that axios is wrong here.

const unsanitizedVar = '/google.com'; // was expecting something like '12345'

const ANY_HTTP_LIBRARY = require(something, maybe axios);
const ANY_EXTERNAL_ENDPOINT = 'https://somewhere.innocent';

this.httpclient = ANY_HTTP_LIBRARY.create({
  baseURL: ANY_EXTERNAL_ENDPOINT,
});

// Isn't >> THIS -the imaginary use case below- << the problem?
this.httpclient.request({ url: `/${unsanitizedVar}` });

even if you can prevent this value from diverting request to another target, you cannot prevent it from doing other kind of malicious things with the assumptions of this vuln report (and the fix).. with my current understanding of it.

---

Axios's (current) baseURL behavior seems like a similar behavior of src= tags of a browser. Which is one possible, and (IMO) well defined design. (not saying "[in]correct"|"good"/"bad")

PS. (edit) Tested browser behavior, using fetch, when on "https://my.site";

> fetch('/12345').then(r => console.log('resp', r.url)); 
..
[XHR] GET https://my.site/12345

> fetch('//www.google.com').then(r => console.log('resp', r.url)); 
..
[XHR] GET https://www.google.com

Same Vuln report would apply to (the design of?) fetch of browsers?

[rrkoshta123]

Is there any way that we can fix this issue, as it is showing no patch available.

[MikeMcC399]

@rrkoshta123

• See at the top of this issue, which points to fix(sec): disregard protocol-relative URL to remediate SSRF #6539
  

[rrkoshta123]

Hi @MikeMcC399, Thanks for replying.
Let's wait for pull request to be merged.

[petewalker]

Axios's (current) baseURL behavior seems like a similar behavior of src= tags of a browser. Which is one possible, and (IMO) well defined design. (not saying "[in]correct"|"good"/"bad")

...

Same Vuln report would apply to (the design of?) fetch of browsers?

The problem here isn't necessarily the behaviour of axios in the browser, it's the behaviour of it in a server-side context where the server is making requests from a private network.

As the report says, in a server-side context, there is no base protocol for a protocol-relative URL to be relative to. Therefore, a protocol-relative URL should not be considered valid in that context.

How the attack could be constructed is sort of secondary to that. If it doesn't make sense in that context, we should disallow it.

[dBiazioli]

@hainenber

Considering @furkanmustafa and @petewalker comments, wouldn't it be the case to update your PR to check if the code is running on server side? So the browser behavior would remain the same...

[jasonsaayman]

I am looking into it

[jasonsaayman]

Please check the note in the PR

[levpachmanov]

@hainenber I see that #6539 was merged, doesn't that make the behavior of axios is inconsistent with https://datatracker.ietf.org/doc/html/rfc3986#section-4.2 ?

[hainenber]

Yes, thats correct. Either me or Jay will need to come up with following PRs to enable protocol relative URLs on client-side only.

Edit: updated with correct word. Thanks Cedric!

[hainenber]

Oh yeah, I accidentally a word there. Thanks for the correction!

[justinmchase]

It would be lovely if a patch fix version could be published since npm audit is now reporting this as a vulnerability and is attempting to recommend rolling me back to version 1.3.1...