T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/api.sh:285- Finding
Incomplete SSRF Protection in Media Fetching
- Content
View full analysis
&2 exit 64 fi host=${url#https://} host=${host%%/*} host=${host%%:*} host=${host,,} # shellcheck disable=SC1009 # shellcheck disable=SC1020 # shellcheck disable=SC1072 # shellcheck disable=SC1073 if [[ -z $host || $host == localhost || $host == *"@"* || $host != *.* || $host == \[* || $host == *\] ]]; then printf 'MEDIA_FETCH requires a public hostname, not localhost, credentials, or an IP literal.\n' >&2 exit 77 fi prepare_media_dir temp_file=$(mktemp "${media_root}/media.XXXXXX") chmod 600 -- "$temp_file" content_type=$( curl \ --silent \ --show-error \ --fail \ --location \ --max-redirs 3 \ --proto '=https' \ --proto-redir '=https' \ --max-filesize 52428800 \ --output "$temp_file" \ --write-out '%{content_type}' \ "$url" ) ``` ### Technical Analysis The helper rejects obvious IP literals, credentials in the authority component, and the literal hostname `localhost`. However, it does not resolve the supplied hostname and verify that every resulting address is public. A syntactically public hostname can resolve to loopback, private, link-local, reserved, or cloud metadata address space. DNS rebinding may also cause a hostname to resolve differently between validation and connection. Because `curl` follows up to three HTTPS redirects, redirect destinations introduce the same problem and are not independently validated. The use of HTTPS and certificate verification reduces some practical exploitation scenarios but does not establish that the destination is public. Internal services may use valid certificates, and an attacker-controlled hostname can resolve to an ...[truncated 1732 chars]- Remediation
View remediation