T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/search-strategy.sh:167
- Finding
- Unrestricted URL Handling Enables Local File Disclosure and Server-Side Request Forgery<![CDATA[ ## Vulnerability Details **File Location**: `scripts/search-strategy.sh`, lines 65–67 and 167–173 **Vulnerability Type**: Unrestricted URL scheme and destination handling **Risk Level**: High ### Vulnerable Code User-supplied URL input is accepted without scheme or destination validation: ```bash url=*) URL="${1#url=}" shift ;; ``` When the `multi` engine is selected, that value is passed directly to `curl`: ```bash if [ -n "$URL" ]; then log_info "目標 URL: $URL" curl -s --compressed "$URL" 2>/dev/null | head -100 || { log_warn "直接存取失敗，嘗試 jina.ai 代理..." curl -s --compressed "https://r.jina.ai/http://$(echo "$URL" | sed -e 's|https://||' -e 's|http://||')" | head -200 } fi ``` ### Technical Analysis The script checks only whether `URL` is nonempty. It does not restrict the URL scheme, validate the destination host, resolve and inspect destination IP addresses, or prevent access to local and private resources. Quoting `"$URL"` prevents shell word splitting and shell metacharacter expansion, but it does not enforce a safe URL policy. Curl supports schemes other than HTTP and HTTPS, including `file://`. Consequently, a caller can cause the process to read files accessible to the operating-system account running the Skill. HTTP destinations are also unrestricted. The process can therefore send requests to loopback interfaces, private networks, link-local addresses, and potentially cloud instance metadata services. This constitutes server-side request forgery when an untrusted party can influence the URL passed to the Skill. Additionally, curl is not given an explicit `--` option terminator. A URL-like input beginning with `-` may be interpreted as a curl command-line option rather than a URL. ### Attack Path #### Local File Disclosure 1. An attacker influences a URL handled by the Agent or directly invokes the Skill with a crafted URL. 2. The attacker explicitly selects the `multi` engine, bypassing the d ...[truncated 1702 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Allow only HTTP and HTTPS** Parse the URL and reject every scheme other than `http` and `https`. Do not rely on string-prefix checks alone. 2. **Reject unsafe destination addresses** Resolve the hostname before making the request and reject all addresses in loopback, private, link-local, multicast, unspecified, and reserved ranges. Apply this policy to both IPv4 and IPv6, including IPv4-mapped IPv6 addresses. 3. **Protect against DNS rebinding** Ensure curl connects to the IP address that was validated. Do not validate one DNS result and then allow curl to perform an independent resolution that may return a different address. 4. **Validate redirects** Either disable redirects or validate the scheme, hostname, and resolved address of every redirect destination before following it. 5. **Terminate curl option processing** Place `--` immediately before the URL: ```bash curl -s --compressed -- "$URL" ``` This prevents an input beginning with `-` from being interpreted as a curl option. 6. **Reject malformed and ambiguous URLs** Reject URLs containing user-information sections, invalid hostnames, control characters, unsupported ports, or parsing ambiguities. Use a dedicated URL parser rather than shell substitutions. 7. **Apply network and filesystem sandboxing** Run retrieval code in an environment without access to sensitive local files, cloud metadata endpoints, loopback administration services, or unrelated private networks. 8. **Fail closed** If validation fails, stop processing and return a clear error. Do not send rejected URLs to a fallback proxy or alternate retrieval tool. ]]>