T09 · Insecure Skill Coding Practices
Note
- Location
- scripts/crawlora.sh:116
- Finding
- Unnecessary Arbitrary POST-Body Transmission to a Third-Party API<![CDATA[ ## Vulnerability Details **File Location**: `scripts/crawlora.sh:34-39, 53-58, 116-124` **Vulnerability Type**: Excessive outbound data transmission capability **Risk Level**: Low ### Vulnerable Code ```bash method="GET" body="" args=() while [ $# -gt 0 ]; do case "$1" in -X) method="$2"; shift 2 ;; -d) body="$2"; shift 2 ;; *) args+=("$1"); shift ;; esac done ``` ```bash case "$method" in GET|POST) ;; *) echo "only GET and POST are supported by the youtube-research skill" >&2 exit 2 ;; esac ``` ```bash if [ "$method" = "GET" ]; then # -G + --data-urlencode URL-encodes each value (so spaces etc. are safe). qs=() for kv in ${rest[@]+"${rest[@]}"}; do [ -n "$kv" ] || continue # curl treats both @file and name@file forms as local-file input for # --data-urlencode. Reject @ outright so query arguments cannot disclose # local files to the Crawlora API. case "$kv" in *@*) echo "@ is not allowed in query arguments" >&2; exit 2 ;; esac qs+=(--data-urlencode "$kv") done curl -fsS -G "${auth[@]}" ${qs[@]+"${qs[@]}"} "${base}${path}" else [ -n "$body" ] || body="${rest[0]:-}" [ -n "$body" ] || body='{}' # Stream the body on stdin so curl never interprets a user value as its # @file shorthand (and cannot read local files supplied in a request body). printf '%s' "$body" | curl -fsS -X "$method" "${auth[@]}" \ -H "Content-Type: application/json" --data-binary @- "${base}${path}" fi ``` ### Technical Analysis The helper accepts `POST` requests and forwards an arbitrary caller-provided body to `https://api.crawlora.net/api/v1`. However, all 13 endpoints documented in `reference/endpoints.md:11-89` use the `GET` method. Arbitrary POST-body support is therefore unnecessary for the Skill's declared YouTube research functionality and exceeds the minimum outbound-data capability required. The destination is fixed to Crawlora over HTTPS, routes are allowlisted, and request bod ...[truncated 2038 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `POST` support and enforce `GET` as the only permitted method for the current endpoint catalog. 2. Remove the `-d` option, body parsing, and POST request branch until a documented endpoint genuinely requires them. 3. Reject any explicit method other than `GET` with a clear error. 4. If POST endpoints are introduced later, maintain an allowlist of exact method-and-path pairs rather than validating methods and paths independently. 5. For any future body-bearing endpoint, validate the JSON schema, permitted field names, value types, and size before transmission. 6. Add tests confirming that `-X POST`, `-d`, unsupported methods, non-catalog routes, and unexpected body data are rejected. A minimal hardening approach is: ```bash method="GET" args=() while [ $# -gt 0 ]; do case "$1" in -X) [ "${2:-}" = "GET" ] || { echo "only GET is supported by the youtube-research skill" >&2 exit 2 } shift 2 ;; -d) echo "request bodies are not supported by the youtube-research skill" >&2 exit 2 ;; *) args+=("$1") shift ;; esac done ``` The request execution can then use only the existing GET branch, eliminating the unused arbitrary-body transmission path. ]]>