T09 · Insecure Skill Coding Practices
- Location
src/api-tester.js:41- Finding
Unrestricted outbound requests enable server-side request forgery
- Content
View full analysis
Vulnerability Details
File Location:
src/api-tester.js, lines 41 and 69-76
Vulnerability Type: Server-Side Request Forgery (SSRF)
Risk Level: HighVulnerable Code
js const url = this._interpolate((this.baseUrl + (test.url || '')));js _request(url, method, body, headers) { const client = url.startsWith('https') ? https : http; const parsed = new URL(url); return new Promise((resolve, reject) => { const req = client.request({ hostname: parsed.hostname, port: parsed.port, path: parsed.pathname + parsed.search, method, headers: { 'Content-Type': 'application/json', ...headers }, timeout: 10000 }, res => {Technical Analysis
The destination URL is derived directly from a test definition and interpolated variables. The implementation then sends a request to the parsed hostname and port without applying an origin allowlist, protocol validation, DNS or IP-address validation, or restrictions for loopback, private, link-local, and cloud metadata networks.
The client selection only checks whether the string starts with
https; all other parseable URL forms are assigned to the HTTP client. Althoughnew URL()rejects many unsupported inputs, the code should explicitly permit onlyhttp:andhttps:rather than relying on indirect behavior.Request methods, headers, and bodies are also test-configurable. Consequently, an attacker who can influence test definitions can issue authenticated or state-changing requests from the network context of the process. Response bodies are returned through test results, allowing readable internal endpoints to disclose their content.
Attack Path
- An attacker supplies or modifies a test definition accepted by the API tester.
- The attacker sets
test.url, or an interpolated URL component, to an internal destination such as a loopback service, private-network host, or link-local metadata endpoint. - The atta ...[truncated 1386 chars]
- Remediation
View remediation
Remediation Suggestions
- Explicitly reject every protocol other than
http:andhttps:. - Require a destination allowlist containing approved hostnames, ports, and schemes. Prefer exact origin matching over suffix or substring checks.
- Resolve destination hostnames before connecting and reject all loopback, private, link-local, multicast, unspecified, and reserved IPv4 and IPv6 ranges.
- Validate every resolved address and ensure the validated address is the address used for the connection to reduce DNS-rebinding and time-of-check/time-of-use risks.
- Block known metadata destinations, including link-local metadata addresses and provider-specific metadata hostnames.
- Apply the same validation to every redirect if redirect support is introduced.
- Require explicit user approval when a test introduces a new origin or sensitive method.
- Do not forward global authorization, cookie, or API-key headers across origins. Bind sensitive headers to explicitly approved origins.
- Consider running the tester in a sandbox with outbound firewall rules that deny internal and metadata networks.
- Add automated tests covering loopback, private IPv4, private IPv6, link-local, encoded IP representations, DNS rebinding, nonstandard ports, and unsupported schemes.
- Explicitly reject every protocol other than
