T09 · Insecure Skill Coding Practices
Error
- Location
- references/endpoints.md:140
- Finding
- Authentication Material Forwarded to an Untrusted Document URL<![CDATA[ ## Vulnerability Details **File Location**: `references/endpoints.md:140-146` **Vulnerability Type**: Cross-origin disclosure of authentication material **Risk Level**: High ### Vulnerable Code ```sh ic_get "/campus/resources/portal/report/all?personID=$PID" \ | jq '.[] | {name, type, url, moduleLabel, endYear}' # download (url may be relative /campus/... or an absolute URL — handle both): DOC_URL='/campus/resources/portal/report/...' # from the .url field above curl -sS -b "$JAR" -H "X-XSRF-TOKEN: $XSRF" -o report-card.pdf \ "$( [[ "$DOC_URL" == http* ]] && echo "$DOC_URL" || echo "$IC_BASE_URL$DOC_URL" )" ``` ### Technical Analysis The document URL originates in a remote API response and may be an absolute URL. The recipe accepts any value beginning with `http` and passes it directly to `curl` while attaching the authenticated cookie jar and `X-XSRF-TOKEN` header. No validation ensures that the URL uses HTTPS or has the same scheme, hostname, and effective port as `IC_BASE_URL`. Consequently, an attacker-controlled absolute URL can receive the XSRF token because the header is added unconditionally. Curl normally applies cookie-domain rules to the cookie jar, which may prevent cookies from reaching an unrelated domain; however, cookies with sufficiently broad domain scope could still be sent to an attacker-controlled related host. The `http*` prefix test is not a security boundary and also permits plaintext HTTP URLs. This behavior exceeds the minimum privileges needed for document retrieval because portal authentication material should only be sent to the trusted district portal origin. ### Attack Path 1. An attacker compromises or influences a document metadata record returned by the portal, or otherwise causes its `url` field to contain an attacker-controlled absolute URL. 2. The user assigns that value to `DOC_URL` as instructed. 3. The `http*` check accepts the URL without validating its scheme or origin. 4. Curl requests the atta ...[truncated 1029 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Permit authenticated downloads only from the exact trusted portal origin: - Resolve relative paths against `IC_BASE_URL`. - Parse the resulting URL with a proper URL parser. - Require the `https` scheme. - Require an exact match of hostname and effective port with `IC_BASE_URL`. - Reject URLs containing user-information fields or otherwise malformed components. 2. Never attach `$JAR` or `X-XSRF-TOKEN` to a cross-origin request. If cross-origin document hosting is an intentional platform feature, use a documented allowlist and omit portal credentials unless the destination explicitly requires a separate, narrowly scoped credential. 3. Do not use a shell prefix check such as `[[ "$DOC_URL" == http* ]]` as URL validation. 4. Configure curl defensively: - Use `--proto '=https'`. - Avoid forwarding credentials across redirects, and validate the final destination before allowing redirects. - Use `--fail-with-body` and appropriate timeouts. - Store downloads with restrictive file permissions. 5. Apply equivalent same-origin validation to every API-provided URL before combining it with authenticated request headers. ]]>