T09 · Insecure Skill Coding Practices
- Location
scripts/script.sh:45- Finding
Unrestricted URL Fetching Enables Server-Side Request Forgery
- Content
View full analysis
/dev/null || echo "000") echo "$code" } ``` The redirect-inspection request is also unrestricted: ```bash redirect_url=$(curl -sL -o /dev/null -w '%{url_effective}' \ --max-time "$TIMEOUT" -A "$USER_AGENT" "$url" 2>/dev/null || echo "(unknown)") ``` The site-crawling command fetches its user-supplied target in the same manner: ```bash page_content=$(curl -sL --max-time 15 -A "$USER_AGENT" "$url" 2>/dev/null || echo "") ``` ### Technical Analysis The `check` and `site` commands accept user-controlled URLs and pass them directly to `curl`. URLs extracted from attacker-influenced files or web pages are also eventually processed by `check_url`. The implementation does not validate the URL scheme, destination hostname, resolved IP address, or network range before initiating a request. The `-L` option instructs `curl` to follow HTTP redirects automatically. Consequently, validating only an initial public hostname would not be sufficient: an attacker-controlled public endpoint can redirect the request to a loopback, private, link-local, or cloud metadata address. No validation is performed on redirect destinations. Potential targets include: - Loopback services such as `127.0.0.1` or `[::1]` - Private network ranges such as `10.0.0.0/8` and `192.168.0.0/16` - Link-local services such as `169.254.169.254` - Internal DNS hostnames accessible from the execution environment - Internal administrative or monitoring endpoints The req ...[truncated 2132 chars]- Remediation
View remediation
