T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/verify_url.sh:4
- Finding
- Unrestricted URL Verification Enables Blind Internal Network Probing## Vulnerability Details **File Location**: `scripts/verify_url.sh`, lines 4–18 **Vulnerability Type**: Server-Side Request Forgery-like unrestricted outbound request **Risk Level**: Medium ### Vulnerable Code ```bash URL="${1:?usage: verify_url.sh <url> [expected_snippet]}" SNIPPET="${2:-}" TMP="$(mktemp)" CODE=$(curl -sSL -o "$TMP" -w "%{http_code}" "$URL" || true) if [ "$CODE" != "200" ]; then echo "FAIL: HTTP $CODE from $URL" rm -f "$TMP" exit 10 fi if [ -n "$SNIPPET" ]; then if ! grep -Fq "$SNIPPET" "$TMP"; then echo "FAIL: snippet not found: $SNIPPET" ``` ### Technical Analysis The script passes the caller-controlled `URL` directly to `curl` without restricting the URL scheme, hostname, resolved IP address, or destination port. The `-L` option also follows redirects without validating each redirect destination. A caller can therefore cause the Agent's execution environment to connect to loopback, private-network, link-local, or otherwise unintended services. The HTTP status check and optional attacker-selected snippet search act as a limited response oracle. For example, the output and exit code can reveal whether an internal endpoint returned HTTP 200 and whether its response contained a selected string. The script does not print the retrieved response body, which limits direct data disclosure, but it still permits blind service discovery and content inference. ### Attack Path 1. An attacker persuades the Agent to verify a deployment URL that points to an internal address, such as a loopback or private-network service. Alternatively, the attacker provides an external URL that redirects to such an address. 2. The Agent invokes `scripts/verify_url.sh` with the attacker-controlled URL and, optionally, an attacker-selected expected snippet. 3. `curl -sSL` requests the destination and follows redirects without checking the final host or resolved address. 4. The script records the response body and evaluates the HTTP status. 5. Its outpu ...[truncated 923 chars]
- Remediation
- ## Remediation Suggestions 1. Restrict accepted URL schemes to `https`, allowing `http` only if it is explicitly required. 2. Prefer an allowlist of approved Puter deployment hostnames or expected application domains. 3. Resolve the destination before connecting and reject loopback, private, link-local, multicast, unspecified, and reserved IPv4 and IPv6 address ranges. 4. Disable redirects or validate the scheme, hostname, port, and resolved address of every redirect target before following it. 5. Restrict destination ports to those required for deployment verification, normally 443 and possibly 80. 6. Add defensive resource limits such as `--connect-timeout`, `--max-time`, `--max-redirs`, and a maximum response-body size. 7. Consider validating the supplied deployment URL against the target recorded during the deployment step rather than accepting an arbitrary URL. 8. Register temporary-file cleanup immediately after creation so interruption and unexpected exits do not leave response data behind: ```bash TMP="$(mktemp)" trap 'rm -f "$TMP"' EXIT ``` 9. Avoid treating user-selected snippet checks as authorization to query arbitrary destinations; destination validation must occur independently before the request.