T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/submit_gpt_4o_image.sh:4
- Finding
- API Credentials and Sensitive Request Data Exposed Through Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/submit_gpt_4o_image.sh`, lines 4–22 **Vulnerability Type**: Sensitive information exposure through command-line arguments **Risk Level**: Medium ### Vulnerable Code ```sh api_key="${POYO_API_KEY:-${1:-}}" if [ -z "$api_key" ]; then echo "Usage: submit_gpt_4o_image.sh [api_key] [payload.json]" >&2 echo "Or set POYO_API_KEY and pass [payload.json]. If no payload file is given, JSON is read from stdin." >&2 exit 1 fi payload="${2:-${1:+}}" if [ -n "${POYO_API_KEY:-}" ]; then payload="${1:-}" fi if [ -n "$payload" ] && [ "$payload" != "$api_key" ]; then body=$(cat "$payload") else body=$(cat) fi curl -sS https://api.poyo.ai/api/generate/submit -H "Authorization: Bearer $api_key" -H 'Content-Type: application/json' -d "$body" ``` ### Technical Analysis The script permits the PoYo API key to be supplied as its first positional command-line argument. Credentials entered this way can be retained in shell history and exposed through process-inspection interfaces while the script is running. The script also expands the API key and the entire JSON request body into the arguments passed to `curl`: ```sh -H "Authorization: Bearer $api_key" -d "$body" ``` Consequently, the `curl` process command line can contain both the Bearer credential and sensitive request content. Depending on the operating system's process-inspection restrictions, another local user, a process running under the same account, or a privileged process may be able to inspect these arguments. Request bodies may contain private prompts, callback URLs, reference-image URLs, mask URLs, or other user-controlled metadata. This issue does not establish remote compromise by itself. Exploitation requires access to command history or sufficient local permission to inspect the affected processes. ### Attack Path 1. A victim invokes the script with the API key as a positional argument or supplies it through `POYO_API_KEY`. 2. ...[truncated 1394 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove support for passing the API key as a positional argument. Require it through a protected secret provider or environment variable and update the usage message accordingly. 2. Avoid expanding authorization headers into `curl` command-line arguments. Prefer an API client library that sets HTTP headers internally. 3. If `curl` must be retained, place the authorization header in a securely created configuration or header file: - Create it with restrictive permissions such as `0600`. - Use a private temporary directory. - Install a shell `trap` to delete it on normal exit and interruption. - Pass only the protected file path to `curl`. 4. Send the JSON body through standard input, for example with `--data-binary @-`, rather than expanding its contents into a command-line argument. 5. Disable shell-history recording around unavoidable secret entry and ensure documentation explicitly warns users never to type API keys as command arguments. 6. Rotate any API key that may previously have been supplied on the command line, and configure the replacement key with the minimum required API permissions and spending limits. 7. Add a regression test that inspects the spawned process arguments and verifies that neither the Bearer token nor the JSON body appears in them. ]]>