T09 · Insecure Skill Coding Practices
- Location
SKILL.md:25- Finding
Hard-Coded API Token and Insecure Plaintext Credential Storage
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:25-32
Vulnerability Type: Hard-coded secret and plaintext credential persistence
Risk Level: Highbash ### API Key配置 ```bash # 环境变量 export QGDATA_TOKEN="Kj9mN2xP5qR8vL3tY7wZ1aB4cD6eF8gH9nX4pL2qR7sT5vY8wZ1aB3cD6eF0gH2i" # 或.env文件 echo "QGDATA_TOKEN=Kj9mN2xP5qR8vL3tY7wZ1aB4cD6eF8gH9nX4pL2qR7sT5vY8wZ1aB3cD6eF0gH2i" >> ~/.openclaw/.envtext ### Technical Analysis The Skill documentation publishes what appears to be a reusable QGData API token and instructs users to persist it in `~/.openclaw/.env`. Hard-coded credentials violate secret-management principles because every recipient of the Skill receives the same credential. The shell command appends the token to a shared plaintext configuration file without creating the file with restrictive permissions or checking its existing ownership and mode. The shared file may also contain credentials belonging to other Skills. Although `scripts/astock_query.py` only parses the `QGDATA_TOKEN` entry, the process receives filesystem-level access to the entire file. The append operation may produce duplicate token entries. Because the parser returns the first matching entry, rotation or replacement by appending a new value may not work as expected. ### Attack Path 1. An attacker downloads the published Skill, examines its documentation, or gains read access to a user's `~/.openclaw/.env`. 2. The attacker extracts the hard-coded `QGDATA_TOKEN`. 3. The attacker configures the token in their own process and invokes the QGData API through the official client or direct supported interfaces. 4. Requests are attributed to the token owner's account until the credential is revoked or expires. 5. If the user's `.env` file has permissive access, another local account or compromised process may similarly recover the persisted token. ### Impact Assessment An attacker could authenticate with the exposed credentia ...[truncated 463 chars]- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed token immediately; assume it has been compromised.
- Remove the real value from the current package, source history, releases, logs, and examples. Use a placeholder such as
YOUR_QGDATA_TOKEN. - Require every user to provide an independently issued token through a secret manager or protected environment variable.
- Prefer environment-only credential handling rather than reading a shared
.envfile. - If file-based storage is unavoidable, use a dedicated credential file, verify ownership, and enforce mode
0600before reading or writing it. - Replace append-based updates with an atomic configuration process that prevents duplicate keys and preserves restrictive permissions.
- Configure minimum server-side token privileges, usage limits, expiration, rotation, and monitoring.
- Avoid exposing raw provider errors if they could contain request or authentication details.
