T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:75
- Finding
- Credentials Exposed Through Command-Line Arguments and URL Query Parameters## Vulnerability Details **File Location**: `SKILL.md`, lines 75, 111, and 123 **Vulnerability Type**: Unsafe credential handling in API request examples **Risk Level**: Medium ### Vulnerable Code ```bash -d "username=admin&password=123456" ``` ```bash curl -s -u "username:password" \ "https://api.example.com/protected" ``` ```bash curl -s "https://api.example.com/protected?api_key=YOUR_KEY" ``` ### Technical Analysis The examples encourage users to place passwords and API keys directly in command-line arguments or URL query parameters. Although the values shown are placeholders, users may replace them with operational credentials when following the examples. Command-line credentials may be retained in shell history and can be exposed through process inspection or command-execution telemetry. An API key placed in a URL query string can additionally appear in server access logs, reverse-proxy logs, monitoring systems, browser history, and debugging output. The warning at line 336 recommends environment variables, but it does not correct the insecure examples or explain the additional risk of placing secrets in URLs. The network access itself is necessary for the declared API-debugging functionality; the issue is the unsafe method used to supply authentication material. ### Attack Path 1. A user copies one of the documented commands and replaces the placeholder with a real password or API key. 2. The command is saved in shell history, exposed in process metadata, or captured by command telemetry. 3. For query-string authentication, the complete URL is also recorded by an API server, proxy, monitoring platform, or other intermediary. 4. A local user, administrator, telemetry operator, or log reader obtains the exposed credential. 5. The credential is replayed against the corresponding API. 6. The attacker gains the API permissions assigned to that credential until it expires or is revoked. ### Imp ...[truncated 539 chars]
- Remediation
- ## Remediation Suggestions - Remove literal password and API-key placement from command examples. - Never transmit API keys in URL query parameters. Use an authorization header or another provider-supported secure authentication mechanism. - Obtain secrets from a secret manager, protected configuration file, or interactive prompt rather than embedding them in reusable commands. - For curl examples, use a permission-restricted configuration file or protected file descriptor so secret-bearing header and authentication values do not appear directly in shell history. - Ensure credential files are readable only by the intended user, such as with filesystem mode `0600`, and exclude them from source control. - Add explicit warnings that environment variables can still be exposed in some process environments and must not be logged. - Redact `Authorization`, API-key, cookie, and password values from verbose output, request logs, debugging traces, and monitoring telemetry. - Replace the query-string example with a header-based pattern and clearly label all values as nonfunctional placeholders. - Recommend short-lived, narrowly scoped testing credentials and immediate rotation if credentials are exposed.