T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- scripts/crawlora.sh:40
- Finding
- Overbroad API Route and HTTP Method Authorization## Vulnerability Details **File Location**: `scripts/crawlora.sh`, lines 40–66 **Vulnerability Type**: Improper API route and method authorization **Risk Level**: Medium ### 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 [ "${#args[@]}" -ge 1 ] || { echo "usage: crawlora.sh [-X METHOD] /path [k=v ... | json-body]" >&2; exit 2; } path="${args[0]}" rest=("${args[@]:1}") # This skill's helper is limited to its documented Crawlora route set. Keep # caller-account surfaces and unrelated API routes out of the helper even if # someone supplies an undocumented path directly. case "$method" in GET|POST) ;; *) echo "only GET and POST are supported by the google-maps-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 google-maps-research skill" >&2 exit 2 ;; esac case "$path" in /google/map/place/*) ;; /google/map/place/*/photos) ;; /google/map/place/*/reviews) ;; /google/map/search) ;; *) echo "path is not in the google-maps-research skill catalog" >&2 exit 2 ;; esac ``` ### Technical Analysis The helper intends to restrict authenticated requests to four documented Google Maps endpoints. However, the shell pattern `/google/map/place/*` accepts every nonempty suffix beneath `/google/map/place/`. In shell pattern matching, `*` can match slash-separated content, so the pattern accepts undocumented paths such as: ```text /google/map/place/example-id/undocumented/action ``` This broad pattern also appears before the narrower `/photos` and `/reviews` patterns, making those patterns ineffective as authorization boundar ...[truncated 1990 chars]
- Remediation
- ## Remediation Suggestions Bind each permitted route to its exact HTTP method instead of validating methods and paths independently: ```bash case "${method}:${path}" in POST:/google/map/search) ;; GET:/google/map/place/*/photos|GET:/google/map/place/*/reviews) place_id="${path#/google/map/place/}" place_id="${place_id%/photos}" place_id="${place_id%/reviews}" case "$place_id" in ""|*/*) echo "invalid place_id" >&2; exit 2 ;; esac ;; GET:/google/map/place/*) place_id="${path#/google/map/place/}" case "$place_id" in ""|*/*) echo "invalid place_id" >&2; exit 2 ;; esac ;; *) echo "unsupported method or path" >&2 exit 2 ;; esac ``` Apply these additional controls: 1. Require `POST` exclusively for `/google/map/search`. 2. Require `GET` exclusively for place details, photos, and reviews. 3. Validate `place_id` as exactly one path segment and reject embedded `/` characters. 4. Match the `/photos` and `/reviews` forms explicitly rather than relying on a broad parent wildcard. 5. Add negative tests for arbitrary child paths, unsupported methods, empty IDs, embedded slashes, and trailing path components. 6. Where possible, enforce the same endpoint allowlist and method restrictions on the server side because client-side validation alone is not a security boundary.