T09 · Insecure Skill Coding Practices
- Location
scripts/extract.mjs:7- Finding
Arbitrary URL Forwarding Enables SSRF and Sensitive URL Disclosure
- Content
View full analysis
Vulnerability Details
File Location:
scripts/extract.mjs, lines 7–13 and 24–32
Vulnerability Type: Arbitrary URL forwarding without destination validation
Risk Level: MediumVulnerable Code
js const args = process.argv.slice(2); if (args.length === 0 || args[0] === "-h" || args[0] === "--help") usage(); const urls = args.filter(a => !a.startsWith("-")); if (urls.length === 0) { console.error("No URLs provided"); usage(); }js const resp = await fetch("https://api.aisa.one/apis/v1/tavily/extract", { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${apiKey}`, }, body: JSON.stringify({ urls: urls, }), });Technical Analysis
The script treats every positional command-line argument as a URL and forwards it to the remote AIsa extraction API. It does not parse destinations with
URL, restrict accepted schemes to HTTP or HTTPS, reject embedded credentials, validate hostnames, resolve DNS records, or block loopback, link-local, private, reserved, and cloud metadata addresses.This creates an SSRF exposure because an attacker-controlled URL can cause the remote extraction service to attempt access to a destination that the caller could not access directly. The request originates from AIsa's infrastructure rather than the local machine, so the reachable scope depends on the extraction service's network placement and server-side protections.
It also creates a disclosure channel: URLs can contain sensitive query parameters, signed tokens, embedded credentials, internal hostnames, tenant identifiers, or confidential paths. The entire URL is transmitted to
api.aisa.one.The network request to AIsa and use of
AISA_API_KEYare otherwise necessary and documented aspects of the declared web-extraction functionality. The excessive privilege is accepting arbitrary destinations without enforcing the minimum ...[truncated 1567 chars]- Remediation
View remediation
Remediation Suggestions
- Parse every supplied destination with
new URL()and reject malformed URLs. - Allow only explicitly required schemes, preferably
https:and, only if necessary,http:. - Reject URLs containing
usernameorpasswordcomponents. - Block
localhost, loopback, unspecified, link-local, private, multicast, reserved, and cloud metadata addresses for both IPv4 and IPv6. - Resolve hostnames before submission and verify every resulting address. Repeat validation after redirects and account for DNS rebinding.
- Enforce equivalent destination restrictions in the remote extraction service; client-side checks alone are not a complete SSRF defense.
- Reject or require explicit confirmation for URLs containing likely secrets, such as signed query parameters, access tokens, session identifiers, or embedded credentials.
- Limit the number and length of submitted URLs to reduce quota abuse and oversized requests.
- Document clearly that submitted URLs are disclosed to AIsa for server-side retrieval.
- Add automated tests covering loopback addresses, RFC1918 ranges, IPv6 local addresses, metadata endpoints, encoded IP representations, redirect chains, and DNS rebinding scenarios.
- Parse every supplied destination with