Can’t get enough of SSRF vulnerabilities, can we now? In this vulnerable npm package we analyze a vulnerability within safe-axios, an open-source npm package designed to safeguard applications from SSRF (Server-Side Request Forgery) attacks. While safe-axios attempts to validate URLs via a denylist, an outdated list creates a bypass window for malicious actors. Let’s explore the technical nitty-gritty and understand the potential consequences.

Demystifying safe-axios: Your (Imperfect) Shield Against SSRF

SSRF vulnerabilities emerge when an application unintentionally makes requests to external servers based on user-controlled input. Attackers can exploit this to fetch internal resources, execute unauthorized actions, or even launch denial-of-service attacks.

safe-axios aims to mitigate this risk by offering URL validation. It maintains a static denylist of IP addresses and ranges considered risky for outbound requests. If a URL resolves to an IP on this list, the request gets flagged as potentially malicious.

However, a closer look reveals a critical flaw in safe-axios’s defense mechanism.

The Vulnerability: A Stale Denylist Opens the Door

The crux of the issue lies in safe-axios’s denylist. This list, meant to identify unsafe IP addresses, is outdated or incomplete. As a result, it overlooks crucial reserved IP address spaces as defined by the IANA (Internet Assigned Numbers Authority).

Specifically, the denylist misses the following reserved ranges:

192.31.196.0/24
192.52.193.0/24
192.175.48.0/24

These ranges are typically used for multicast traffic and other special purposes within local networks. While exploiting them for SSRF attacks might be less common, it highlights a vulnerability in safe-axios’s logic.

For a more robust safety net, SSRF protection libraries should adhere to established standards for identifying invalid public IP addresses. Notably, popular npm packages like ipaddr.js correctly classify these ranges as reserved.

A Practical Demonstration of SSRF Bypass Proof of Concept (PoC)

To illustrate the bypass, let’s consider the following proof of concept example and SSRF reproducible scenario:

1. Install the safe-axios package:

2. Define an app.js file with the programmatic API of safe-axios:

import SafeAxios from 'safe-axios';
async function main() {
    const safeAxios = SafeAxios.default;
    // this request is allowed by safe axios even though it is in a reserved IP address space
    const data = await safeAxios.request({url: 'https://192.32.196.4/test'});
}
main();

As you can see, safe-axios incorrectly validates a URL with a reserved IP address, potentially allowing an attacker to exploit this vulnerability.

SSRF Proof of Concept Exploit Payload

I disclosed this vulnerability to the safe-axios maintainers via a GitHub issue, and detailed this headers redirect bypass in a full security vulnerability disclosure report.