T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/cf.sh:13
- Finding
- Cloudflare API Token Exposed Through Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/cf.sh`, lines 13–17 **Vulnerability Type**: Bearer token disclosure through command-line arguments **Risk Level**: Medium ### Vulnerable Code ```bash TOKEN="${CLOUDFLARE_API_TOKEN:?Set CLOUDFLARE_API_TOKEN}" _curl() { curl -sS -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" "$@" } ``` ### Technical Analysis The `_curl` function expands `CLOUDFLARE_API_TOKEN` into the `curl` command-line argument containing the `Authorization` header. Consequently, the bearer token may appear in the process argument vector while `curl` is running. On systems where process arguments are visible to other local users, privileged monitoring software, process auditing systems, or diagnostic tooling, an observer may recover the token from process listings or process metadata. The exposure window is limited to the lifetime of each `curl` process, but repeated API operations create repeated opportunities for collection. The token is not hardcoded in the repository and is transmitted to the legitimate Cloudflare HTTPS endpoint. The issue specifically concerns local disclosure through process arguments. ### Attack Path 1. The operator configures `CLOUDFLARE_API_TOKEN` and invokes a command provided by `scripts/cf.sh`. 2. The script launches `curl` with an argument containing `Authorization: Bearer <token>`. 3. An attacker with sufficient local process-inspection access monitors running processes or obtains command-line telemetry collected by system monitoring software. 4. The attacker captures the `curl` argument while the API request is in progress and extracts the bearer token. 5. The attacker submits requests directly to the Cloudflare API using the stolen token. 6. Successful actions are limited by the token's configured Cloudflare scopes and resource restrictions. ### Impact Assessment A stolen token grants access to every Cloudflare API capability authorized by that token. Depending on ...[truncated 606 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Avoid passing the bearer token directly as a command-line argument. 1. Provide the sensitive header to `curl` through a configuration stream or a securely created temporary configuration file rather than through `-H` on the command line. 2. If a temporary file is necessary: - Create it with `mktemp`. - Set a restrictive `umask`, such as `077`, before creation. - Ensure only the current user can read it. - Register a `trap` to remove it on normal exit and interruption. - Do not place it in a shared or predictable path. 3. Ensure shell tracing is disabled around credential handling so that the token is not written to logs. 4. Use narrowly scoped Cloudflare API tokens restricted to only the required permissions, accounts, and zones. 5. Rotate the token if process arguments may already have been captured by monitoring, audit, or diagnostic systems. 6. Review operating-system process visibility controls and restrict access to process metadata where possible. One possible approach is to pass a curl configuration through standard input: ```bash _curl() { printf '%s\n' \ 'silent' \ 'show-error' \ "header = \"Authorization: Bearer $TOKEN\"" \ 'header = "Content-Type: application/json"' | curl --config - "$@" } ``` The implementation should also be tested on all supported curl versions to confirm that configuration input and diagnostic output do not expose the credential. ]]>