T09 · Insecure Skill Coding Practices
Error
- Location
- references/ofox-image.sh:146
- Finding
- API Key Disclosure Through an Unrestricted Endpoint Override<![CDATA[ ## Vulnerability Details **File Location**: `references/ofox-image.sh:146` and `references/ofox-image.sh:1555-1563` **Vulnerability Type**: Credential exfiltration through an attacker-controlled API endpoint **Risk Level**: High ### Vulnerable Code ```bash API_BASE="${OFOX_API_BASE_URL:-https://api.ofox.ai/v1}" ``` ```bash local tmp_body http_code curl_rc body tmp_body=$(mktemp) http_code=$(curl -sS -o "$tmp_body" -w '%{http_code}' \ --connect-timeout "$CONNECT_TIMEOUT" --max-time "$GENERATE_MAX_TIME" \ -X POST "$API_BASE/images/generations" \ -H "Authorization: Bearer $OFOX_API_KEY" \ -H "Content-Type: application/json" \ -d "$payload") ``` Related instructions in `SKILL.md:38-42` recommend sourcing an authorized dotenv file and acknowledge that `OFOX_API_BASE_URL` can silently redirect API calls: ```markdown Locate it (`.env` at the repo root is the usual spot), then `set -a; . <path>; set +a` in the shell you'll call the script from. Sourcing a dotenv pulls in *every* variable in the file, not just the key — `OFOX_API_BASE_URL` is one this script reads, and it silently redirects every API call — so read the file before you load it. ``` ### Technical Analysis The destination of the authenticated image-generation request is taken directly from the `OFOX_API_BASE_URL` environment variable. The script does not validate that the resulting URL: - Uses HTTPS. - Belongs to the trusted `api.ofox.ai` origin. - Contains no embedded user information. - Is an explicitly authorized development endpoint. The same request includes `Authorization: Bearer $OFOX_API_KEY`. Consequently, any process or sourced environment file that controls `OFOX_API_BASE_URL` controls where the production API credential is transmitted. This is especially risky because the Skill instructs the Agent to source dotenv files with: ```bash set -a; . /path/to/.env; set +a ``` That operation imports every variable and executes the file as shell code rather than reading ...[truncated 2016 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Pin production requests to the trusted Ofox origin.** For normal authenticated operation, use a constant endpoint: ```bash readonly API_BASE="https://api.ofox.ai/v1" ``` 2. **If endpoint overrides are required for testing, make them explicitly unsafe and opt-in.** Require a separate switch such as `OFOX_ALLOW_CUSTOM_API_BASE=1`, and reject overrides by default. 3. **Never forward the production key to a custom origin.** Require a separate development credential variable when a custom endpoint is enabled: ```bash if [ -n "${OFOX_API_BASE_URL:-}" ]; then [ "${OFOX_ALLOW_CUSTOM_API_BASE:-}" = "1" ] || exit 2 API_KEY="${OFOX_CUSTOM_API_KEY:-}" else API_BASE="https://api.ofox.ai/v1" API_KEY="${OFOX_API_KEY:-}" fi ``` 4. **Validate URL properties before transmission.** At minimum, require HTTPS, reject URL user information, and compare the parsed hostname and port against an allowlist. 5. **Avoid sourcing dotenv files as shell scripts.** Read only the required variable using a parser that does not execute file content. Do not import unrelated variables into the generation process. 6. **Use a reduced environment when invoking the client.** Explicitly unset endpoint override variables unless the user separately approved a custom endpoint. 7. **Add regression tests** proving that an unapproved custom origin cannot receive `OFOX_API_KEY` and that plaintext HTTP endpoints are rejected. ]]>