T09 · Insecure Skill Coding Practices
- Location
references/examples.md:607- Finding
Server-Side Request Forgery Through Unrestricted Link Validation
- Content
View full analysis
Vulnerability Details
File Location:
references/examples.md, lines 607-623
Vulnerability Type: Server-Side Request Forgery (SSRF)
Risk Level: MediumVulnerable Code
typescript private async validateLink(link: string): Promise<boolean> { if (link.startsWith('http')) { // Check external link try { const response = await fetch(link, { method: 'HEAD' }); return response.ok; } catch { return false; } } else { // Check local file try { await fs.access(path.join(this.config.projectPath, link)); return true; } catch { return false; } } }Technical Analysis
The documentation generator extracts links from project-controlled content and sends a server-side
HEADrequest to any string beginning withhttp. It does not parse and validate the URL, restrict destinations, resolve and inspect host addresses, block internal network ranges, constrain redirects, or apply an explicit timeout.An attacker able to introduce a Markdown link into analyzed documentation could therefore cause an implementation based on this example to request attacker-selected network destinations. Potential targets include loopback services, private-network hosts, link-local addresses, and cloud metadata services. DNS rebinding and redirects may also bypass simplistic hostname checks unless every resolved address and redirect destination is validated.
Although
HEADrequests may reduce response-body exposure, they still permit network reachability probing and can trigger state-changing behavior in services that incorrectly processHEAD. This issue is present in reference example code rather than an automatically executed packaged script.Attack Path
- The attacker gains the ability to add or modify documentation content analyzed by the generator.
- The attacker inserts a Markdown link targeting an internal resource, such as
http://127.0.0.1:PORT/pathor a private-network service ...[truncated 1114 chars]
- Remediation
View remediation
Remediation Suggestions
- Parse each candidate with the standard
URLAPI and allow only explicitly required schemes, preferably HTTPS. - Use an allowlist of approved hostnames where external link checking does not require unrestricted Internet access.
- Resolve the hostname before connecting and reject every address in loopback, private, link-local, multicast, reserved, and cloud-metadata ranges for both IPv4 and IPv6.
- Revalidate the resolved address immediately before connection to mitigate DNS rebinding.
- Disable automatic redirects or validate every redirect destination using the same scheme, hostname, and IP-address rules.
- Apply strict connection and total-request timeouts, response-size limits, concurrency limits, and request-rate limits.
- Run link validation in a sandbox with outbound firewall rules that deny access to internal networks and metadata services.
- Avoid exposing detailed network errors or status differences to untrusted users.
- Consider making external link validation opt-in or delegating it to a restricted CI service.
- Parse each candidate with the standard
