T09 · Insecure Skill Coding Practices
Warning
- Location
- config.yaml:7
- Finding
- Plaintext API Credential Storage Contradicts the Encryption Claim## Vulnerability Details **File Location**: `config.yaml:7-12`; related instructions in `SKILL.md:50-53, 88-92` **Vulnerability Type**: Plaintext sensitive-data storage **Risk Level**: Medium ### Vulnerable Code ```yaml api: # Pinduoduo Open Platform API configuration # Obtain credentials from: https://open.pinduoduo.com/ app_key: "" # To be filled in app_secret: "" # To be filled in access_token: "" # To be filled in ``` The corresponding documentation directs users to edit this configuration file and claims that API keys are stored in encrypted form: ```markdown # Edit the configuration file nano ~/.openclaw/workspace/skills/pinduoduo-automation/config.yaml # Fill in the shop ID, API key, etc. ``` ```markdown ## Security Notes - API keys stored encrypted - Operation logging - Sensitive-data masking - Principle of least privilege ``` ### Technical Analysis The configuration schema provides ordinary YAML string fields for an application key, application secret, and access token. No encryption, secret-manager integration, runtime environment-variable loading, permission validation, or masking implementation exists in the audited files. Users following the documented setup process would therefore place credentials directly into a plaintext file. The documentation's encryption claim may give users a false assurance that these values receive cryptographic protection. Plaintext credentials can be disclosed through source-control commits, backups, support bundles, package redistribution, permissive filesystem permissions, or access by another process running under the same account. ### Attack Path 1. A user follows `SKILL.md` and enters valid Pinduoduo credentials into `config.yaml`. 2. The values remain as plaintext because the project implements no encryption or protected credential storage. 3. The configuration is copied into source control, a backup, an archive, or ...[truncated 807 chars]
- Remediation
- ## Remediation Suggestions 1. Remove secret values from distributable YAML configuration files. 2. Load credentials at runtime from a supported operating-system secret store, dedicated secret manager, or protected environment injection mechanism. 3. If a local credential file is unavoidable, keep it outside the project/package directory, enforce owner-only permissions such as mode `0600`, and reject files with unsafe ownership or permissions. 4. Add all local secret-bearing files to source-control and packaging exclusion rules. 5. Provide a committed example configuration containing only placeholders and non-sensitive settings. 6. Remove the encrypted-storage claim until encryption is actually implemented and verified. 7. Avoid logging or displaying secrets, and redact credential fields from diagnostics and error output. 8. Document credential rotation and revocation procedures for users who may already have stored or committed secrets in this file.