T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:39
- Finding
- Sensitive credentials are accepted through command-line arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:39-48`, `SKILL.md:68-70`; `references/commands.md:5-7`, `references/commands.md:18` **Vulnerability Type**: Exposure of API keys and OAuth tokens through process arguments **Risk Level**: Medium ### Vulnerable Code From `SKILL.md:39-48`: ```bash proxygate listings create --non-interactive \ --service-name "My API" \ --base-url "https://api.example.com" \ --auth-pattern bearer \ --api-key "your-api-key" \ --price 5000 \ --total-rpm 100 \ --categories ai \ --description "Fast Llama 3.3 access" ``` From `SKILL.md:68-70`: ```bash # Rotate API key or OAuth2 credentials (no downtime) proxygate listings rotate-key <id> --key <new-api-key> proxygate listings rotate-key <id> --oauth2 <new-token> ``` From `references/commands.md:5-7`: ```markdown - `--gateway <url>` — Override gateway URL (default: https://gateway.proxygate.ai) - `--keypair <path>` — Path to Solana keypair JSON file - `--api-key <key>` — Override API key ``` From `references/commands.md:18`: ```bash proxygate login --key pg_live_... # authenticate with API key ``` ### Technical Analysis The documented workflows place ProxyGate API keys, upstream API keys, and OAuth tokens directly in command-line arguments. Once placeholders are replaced with real credentials, those values may become visible through: - Shell history files. - Process listings such as `ps`, `/proc/<pid>/cmdline`, or process-monitoring software. - Terminal capture and session-recording systems. - CI/CD logs and command tracing. - Agent transcripts or tool-execution logs. - Crash diagnostics and observability platforms that record process arguments. This conflicts with the principle that sensitive values should be transmitted using channels designed to suppress disclosure, such as protected standard input, no-echo interactive prompts, credential stores, or restricted-permission secret files. The documented `--gateway <url>` option inc ...[truncated 2516 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Avoid secrets in command-line arguments** - Add support for reading API keys and OAuth tokens from protected standard input. - Use interactive no-echo prompts for manual authentication and rotation. - Integrate with operating-system credential stores or dedicated secret managers. - Support restricted-permission secret files without printing their contents. 2. **Use environment variables only with appropriate safeguards** - If environment variables are supported, document their exposure limitations. - Do not print secret-bearing environment variables in debug or CI logs. - Prefer secret-manager injection over persistent shell-profile configuration. 3. **Protect command and execution logs** - Redact values supplied to `--api-key`, `--key`, and `--oauth2`. - Ensure CLI error messages, telemetry, and crash reports do not include raw arguments. - Mark credential parameters as sensitive in any structured logging system. 4. **Harden custom gateway handling** - Require explicit confirmation when credentials will be sent to a non-default gateway. - Permit only HTTPS gateway URLs by default. - Clearly display the destination hostname before authentication. - Consider an allowlist or trust-on-first-use mechanism for custom gateways. - Do not forward credentials across redirects to a different origin. 5. **Improve documentation** - Replace secret-bearing examples with secure stdin, prompt, credential-store, or secret-file workflows. - Add a warning that literal secrets must not be placed in shell commands, scripts, source control, transcripts, or CI configuration. - Document credential revocation and rotation procedures for suspected exposure. 6. **Recommended interface patterns** - Provide commands such as `proxygate login --key-stdin`. - Provide commands such as `proxygate listings rotate-key <id> --key-stdin`. - Alternatively, prompt securely when a secret option is ...[truncated 13 chars]