T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:49
- Finding
- Database Credentials Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:49-51, 68-70` **Vulnerability Type**: Credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```bash # PostgreSQL psql "postgresql://user:password@host:5432/dbname" -c "\dt" psql "postgresql://user:password@host:5432/dbname" -c "\d table_name" psql "postgresql://user:password@host:5432/dbname" -c "SELECT count(*) FROM table_name;" # Redis redis-cli -h host -p 6379 -a password INFO keyspace redis-cli -h host -p 6379 -a password DBSIZE redis-cli -h host -p 6379 -a password KEYS "*" ``` ### Technical Analysis The documented examples instruct users to place database passwords directly in command-line arguments. If users replace the placeholders with real credentials, those secrets can be retained in shell-history files, terminal session logs, audit records, and automation logs. Depending on the operating system and process isolation settings, command arguments may also be visible to other local users through process-inspection interfaces. Using a password-bearing connection string does not prevent this disclosure when the entire string is supplied as a command-line argument. This behavior also contradicts the safety statement at `SKILL.md:80`, which says passwords should not be placed in history. ### Attack Path 1. A user follows the documented example and replaces `password` with a valid database password. 2. The resulting command is saved in shell history, captured by logging infrastructure, or exposed through process inspection while it is running. 3. A local user, administrator of a shared logging service, or attacker with access to the affected history or logs retrieves the credential. 4. The attacker connects to the database using the exposed account. 5. The attacker exercises all permissions assigned to that account, potentially including reading, modifying, exporting, or deleting database records. ### Impact Assessment The obtainabl ...[truncated 364 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Remove all examples that place passwords directly in command-line arguments or password-bearing URLs. - For PostgreSQL, use a protected `.pgpass` file with permissions set to `0600`, a suitable credential manager, or an interactive password prompt. - For MySQL, use `mysql_config_editor` or a protected option file rather than the `-pPASSWORD` form. - For Redis, use a protected configuration or credential mechanism supported by the deployed client instead of `-a password`. - Ensure secrets are not interpolated into commands printed to logs or displayed for confirmation. - Disable or carefully control shell history for emergency commands involving secrets, while recognizing that this does not address process-list or audit-log exposure. - Use dedicated least-privilege database accounts and rotate any credential that may already have been entered using these examples. - Revise the safety rule at `SKILL.md:80` to clarify that password-bearing connection strings are unsafe when supplied directly as visible command arguments. ]]>