T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/crawlora.sh:44
- Finding
- Helper Permits Undocumented POST Requests and Overly Broad Product Routes<![CDATA[ ## Vulnerability Details **File Location**: `scripts/crawlora.sh`, lines 44–68 and 99–104 **Vulnerability Type**: Excessive API capabilities and insufficient route validation **Risk Level**: Medium ### Vulnerable Code ```bash case "$method" in GET|POST) ;; *) echo "only GET and POST are supported by the ulta-research skill" >&2 exit 2 ;; esac # Reject path syntax that could smuggle a route through a shell glob check. case "$path" in ""|*[?#%]*|*..*|*//* ) echo "invalid path for the ulta-research skill" >&2 exit 2 ;; esac case "$path" in /ulta/categories) ;; /ulta/category) ;; /ulta/product/*) ;; /ulta/product/questions) ;; /ulta/product/reviews) ;; /ulta/search) ;; /ulta/stores) ;; /ulta/suggest) ;; *) echo "path is not in the ulta-research skill catalog" >&2 exit 2 ;; esac ``` ```bash 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 endpoint reference defines all eight operations exposed by this Skill as `GET` requests. Nevertheless, the helper accepts both `GET` and `POST` for every allowlisted path and forwards an arbitrary caller-controlled JSON body for POST requests. The route allowlist is also broader than the documented interface. The pattern `/ulta/product/*` accepts any descendant beginning with `/ulta/product/`, rather than accepting only a single validated product identifier. For example, additional undocumented path segments can pass the local check. Together, these behaviors violate least-capability principles: the helper exposes HTTP methods and route shapes that are not required for the declared Ulta research functionality. Requ ...[truncated 2155 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Restrict the helper to the only documented method: ```bash if [ "$method" != "GET" ]; then echo "only GET is supported by the ulta-research skill" >&2 exit 2 fi ``` 2. Remove POST body parsing and the POST-specific curl branch entirely. Eliminating unused functionality is safer than retaining dormant generic request support. 3. Validate product-detail routes as exactly one product identifier. For example: ```bash case "$path" in /ulta/categories|\ /ulta/category|\ /ulta/product/questions|\ /ulta/product/reviews|\ /ulta/search|\ /ulta/stores|\ /ulta/suggest) ;; /ulta/product/[A-Za-z0-9_-]*) product_id="${path#/ulta/product/}" case "$product_id" in ""|*[!A-Za-z0-9_-]*) echo "invalid Ulta product ID" >&2 exit 2 ;; esac ;; *) echo "path is not in the ulta-research skill catalog" >&2 exit 2 ;; esac ``` 4. Prefer separate wrapper functions for each endpoint rather than accepting a generic method and path. Each wrapper should allow only documented parameters and validate numeric fields, pagination, coordinates, radius, SKU, and product IDs. 5. Add regression tests confirming that POST, nested product descendants, encoded path separators, query fragments embedded in paths, and unsupported routes are rejected before curl executes. 6. Retain the existing fixed HTTPS base URL, API-key character validation, private temporary configuration, cleanup trap, and rejection of curl `@file` query syntax. ]]>