T09 · Insecure Skill Coding Practices
- Location
scripts/bilibili-download.sh:17- Finding
Unrestricted User-Supplied URL Enables Blind Server-Side Request Forgery
- Content
View full analysis
Vulnerability Details
File Location:
scripts/bilibili-download.sh, line 17
Vulnerability Type: Blind server-side request forgery through an unrestricted URL
Risk Level: MediumVulnerable Code
bash BV=$(curl -sI "$INPUT" 2>/dev/null | grep -i location | grep -oE 'BV[a-zA-Z0-9]+' | head -1)Technical Analysis
When the first argument is not syntactically recognized as a Bilibili BV identifier, the script passes it directly to
curl. The argument is properly shell-quoted, so this is not shell command injection; however, no URL scheme, hostname, destination address, or port validation is performed.Consequently, a caller can cause the environment running the skill to issue a HEAD request to an arbitrary destination accessible from that environment. This includes loopback services, private network hosts, cloud metadata services, and other endpoints unavailable to the external caller.
The response is filtered for a
Locationheader containing a BV-like value, which limits direct response disclosure. Nevertheless, observable success, failure, timing, and script behavior can provide a blind SSRF oracle. An internal endpoint returning an attacker-influenced redirect with a BV-like value could also cause the workflow to proceed using that identifier.Attack Path
- An attacker supplies a URL instead of a valid BV identifier, such as an internal HTTP endpoint or a loopback service.
- An agent or user invokes
bilibili-download.shwith that attacker-controlled argument. - The script executes
curl -sIagainst the supplied destination from the skill runner's network context. - The attacker compares completion time, failure behavior, or subsequent script output to infer whether the destination is reachable.
- By repeating requests against different hosts and ports, the attacker may perform blind internal-network discovery. If a reachable endpoint performs an action on a HEAD request, that act ...[truncated 574 chars]
- Remediation
View remediation
Remediation Suggestions
- Parse the input as a URL and allow only
https. - Restrict accepted hostnames to the intended Bilibili short-link domains, such as an exact allowlist containing
b23.tv. - Reject URLs containing user information, unexpected ports, malformed hostnames, or non-HTTPS schemes.
- Resolve the hostname before making the request and reject loopback, link-local, private, multicast, reserved, and unspecified IP ranges for both IPv4 and IPv6.
- Protect against DNS rebinding by ensuring that the address used for the connection is the validated address.
- Apply strict connection and total timeouts, response-size limits, and a limited redirect count.
- Revalidate the hostname and resolved address at every redirect hop if redirects are enabled.
- Prefer accepting only a BV identifier. If short-link expansion is necessary, isolate it in a network sandbox without access to internal services.
Example validation approach:
bash case "$INPUT" in https://b23.tv/*) ;; *) echo "Error: only HTTPS b23.tv short links or BV identifiers are accepted" exit 1 ;; esacHostname allowlisting should be supplemented with resolved-address validation rather than relying solely on a string prefix.
- Parse the input as a URL and allow only