T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:20
- Finding
- Unrestricted URL Requests Enable Server-Side Request Forgery## Vulnerability Details **File Location**: `SKILL.md`, lines 20–22 and 43–44 **Vulnerability Type**: Server-Side Request Forgery (SSRF) caused by unrestricted URL handling **Risk Level**: Medium ### Vulnerable Code ```powershell try { $response = Invoke-WebRequest -Uri $url -Method Head -TimeoutSec 10 return @{ ``` A second unrestricted request retrieves the response content: ```powershell # Check URL matches claimed content type $response = Invoke-WebRequest -Uri $url ``` ### Technical Analysis The skill instructs the executor to pass an arbitrary `$url` directly to `Invoke-WebRequest`. It does not validate the URL scheme or destination, restrict allowed hosts or ports, resolve and inspect destination IP addresses, block loopback/private/link-local/reserved networks, or safely control redirects. Consequently, an attacker-controlled evidence URL can make the system running the skill issue HEAD and GET requests from its own network context. Redirects may also be used to bypass superficial checks unless every redirect destination is independently validated. The GET request has no documented response-size limit, creating an additional resource-exhaustion concern. ### Attack Path 1. An attacker supplies an evidence URL targeting a loopback, private-network, link-local, cloud metadata, or attacker-controlled redirect endpoint. 2. The verifier assigns that value to `$url` without validating its destination. 3. `Invoke-WebRequest` sends a HEAD request, and the content-verification step may subsequently send a GET request. 4. The request originates from the verifier host and can reach services unavailable to the external attacker. 5. Status codes, content types, error details, and potentially response content are processed by the workflow, enabling internal-service discovery or disclosure. ### Impact Assessment Exploitation does not directly grant operating-system privileges or code execution. It can, ...[truncated 371 chars]
- Remediation
- ## Remediation Suggestions - Allow only explicitly required schemes, preferably `https`. - Use an allowlist of approved evidence hosts where operationally possible. - Reject URLs containing embedded credentials, unexpected ports, malformed hostnames, or unsupported schemes. - Resolve the hostname before connecting and reject loopback, private, link-local, multicast, reserved, and cloud-metadata address ranges for both IPv4 and IPv6. - Prevent DNS rebinding by ensuring the validated address is the address used for the connection. - Disable redirects or validate the scheme, hostname, port, and resolved IP address at every redirect hop. - Explicitly deny known metadata endpoints and internal service domains. - Apply connection, request, and total-operation timeouts to both HEAD and GET requests. - Stream response bodies with strict byte limits rather than loading unrestricted content into memory. - Return only the minimum verification result and avoid exposing response bodies or detailed internal connection errors. - Enforce outbound firewall or proxy rules so application-level validation is backed by network-level controls.