T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/mosi_dialogue.sh:70
- Finding
- API Credential Exposure Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/mosi_dialogue.sh`, lines 70 and 117-120; documented in `SKILL.md`, line 110 **Vulnerability Type**: API credential disclosure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```bash --api-key|-k) API_KEY="$2"; shift 2 ;; ``` ```bash RESPONSE=$(curl -sf -X POST \ "https://studio.mosi.cn/api/v1/audio/speech" \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ --max-time 1800 \ -d "$PAYLOAD") ``` The corresponding documented option is: ```text --api-key, -k KEY Override MOSI_TTS_API_KEY env var ``` ### Technical Analysis The script permits users to provide the MOSI API key through the `--api-key` command-line option. A key supplied this way may be recorded in shell history and is included in the argument list of the running shell script. The script also expands the key into curl's `Authorization` header argument. Consequently, the bearer token can appear in curl's process argument list for the duration of the network request. Because the request permits a timeout of up to 1,800 seconds, a slow or stalled request may increase the period during which the credential is observable. Process arguments may be accessible through operating-system process inspection interfaces to other local users or processes, depending on host permissions and process isolation. This is not remote credential disclosure by itself; exploitation requires suitable local access or access to retained command history. ### Attack Path 1. A user invokes the script with `--api-key SECRET`, or the script expands `MOSI_TTS_API_KEY` into curl's authorization-header argument. 2. The secret is retained in shell history when entered directly on the command line, or becomes visible in the process arguments while the script or curl process is running. 3. A local attacker or compromised process with p ...[truncated 684 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the `--api-key` option and require the credential to be supplied through a protected secret store or environment variable. 2. Avoid placing the authorization header directly in curl's command-line arguments. Pass sensitive curl configuration through standard input, for example: ```bash printf 'header = "Authorization: Bearer %s"\n' "$API_KEY" | curl --config - \ --fail --silent --show-error \ --request POST \ "https://studio.mosi.cn/api/v1/audio/speech" \ -H "Content-Type: application/json" \ --max-time 1800 \ --data-binary "$PAYLOAD" ``` 3. If standard-input configuration is unsuitable, use a temporary curl configuration file created with restrictive permissions such as mode `0600`, install cleanup traps, and securely remove the file immediately after use. 4. Document that users must not place credentials directly in shell commands. Recommend a platform-supported secret manager and ensure logs never print the key. 5. Clear the in-memory shell variable with `unset API_KEY` after the request where practical, and rotate any credential suspected of prior exposure. 6. Harden host process visibility, such as restricting `/proc` access, as defense in depth rather than as the primary fix.