T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:59
- Finding
- Plaintext Storage of Long-Lived API Credentials## Vulnerability Details **File Location**: `SKILL.md`, lines 59–72 **Vulnerability Type**: Plaintext sensitive credential storage **Risk Level**: Medium ### Vulnerable Code ```markdown Or configure in `~/.openclaw/openclaw.json`: ```json { "skills": { "entries": { "organizze": { "enabled": true, "env": { "ORGANIZZE_EMAIL": "seu_email@exemplo.com", "ORGANIZZE_API_TOKEN": "seu_token_aqui", "ORGANIZZE_USER_AGENT": "Nome Completo (seu_email@exemplo.com)" } } } } } ``` ``` ### Technical Analysis The setup documentation recommends storing the Organizze account email and a long-lived API token directly in a plaintext JSON configuration file. It does not require owner-only file permissions, encryption at rest, an operating-system credential store, or another secret-management mechanism. This creates a mismatch with the skill's stated credential-protection rules. Environment-variable references prevent credentials from being embedded in generated shell commands, but they do not protect credentials when their source is an unprotected plaintext file. Local users, compromised processes, backup systems, synchronization software, or accidentally shared diagnostic archives may be able to read the configuration. The token is subsequently used as the password in HTTP Basic authentication for API operations. Therefore, disclosure of both configured values can allow an attacker to authenticate independently of the skill. ### Attack Path 1. A user follows the documented setup procedure and places the Organizze email and API token in `~/.openclaw/openclaw.json`. 2. The file is created with permissive permissions, copied into an insecure backup, synchronized to another system, included in a support archive, or read after a local account/process compromise. 3. An attacker extracts `ORGANIZZE_EMAIL` and `ORGANIZZE_API_TOKEN` from the plaintext JSON. 4. The attacker uses those credentials with HTTP ...[truncated 740 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the recommendation to store the API token directly in a general-purpose plaintext JSON configuration file. 2. Prefer an operating-system keychain, encrypted credential manager, or secret-management integration supported by the runtime. 3. If file-based secret injection is unavoidable: - Store secrets in a dedicated file outside the project and synchronization directories. - Restrict the file and its parent directory to the owning user. - On POSIX systems, document owner-only permissions such as `chmod 600` for the secret file. - Ensure the file is excluded from version control, backups, logs, diagnostics, and support bundles where appropriate. 4. Keep configuration files limited to references identifying where secrets should be loaded, rather than containing the secret values themselves. 5. Document immediate token revocation and rotation procedures for suspected disclosure. 6. Use the narrowest API authorization available and periodically rotate long-lived tokens. 7. Preserve the existing HTTPS-only endpoint restriction and continue preventing credentials from being printed, logged, or included in model-visible output.