T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:40
- Finding
- Bearer Token Stored Without Restrictive File Permissions## Vulnerability Details **File Location**: `SKILL.md`, lines 40–43 **Vulnerability Type**: Insecure local credential storage **Risk Level**: Medium ```bash # Save for later mkdir -p ~/.openclaw/workspace/skills/diarybeast echo "$TOKEN" > ~/.openclaw/workspace/skills/diarybeast/.token echo "$ADDRESS" > ~/.openclaw/workspace/skills/diarybeast/.address ``` ### Technical Analysis The bearer token is written to a regular file without first establishing restrictive directory and file permissions. The resulting permissions depend on the process umask. Under common configurations, the directory may be created as `0755` and the token file as `0644`, potentially allowing other local users or processes to read the credential. According to the documentation, the session remains valid for 24 hours. Possession of the token is sufficient to invoke authenticated DiaryBeast API endpoints as the associated wallet identity. ### Attack Path 1. A user authenticates and follows the documented token-storage instructions. 2. The shell creates `.token` with permissions derived from a permissive umask. 3. Another local user or compromised process reads `~/.openclaw/workspace/skills/diarybeast/.token`. 4. The attacker supplies the stolen value through the `Authorization: Bearer` header. 5. The attacker invokes authenticated endpoints before the session expires. ### Impact Assessment An attacker with local filesystem access could impersonate the affected DiaryBeast account for the remaining token lifetime. Based on the documented endpoints, this may permit creating diary entries, changing profile or onboarding data, purchasing items with in-app tokens, feeding the pet, generating paid summaries, and otherwise modifying account state. This issue does not expose the underlying wallet private key, and the demonstrated scope is limited to permissions granted by the DiaryBeast bearer session.
- Remediation
- ## Remediation Suggestions - Set a restrictive umask before creating credential files: ```bash umask 077 mkdir -p ~/.openclaw/workspace/skills/diarybeast printf '%s\n' "$TOKEN" > ~/.openclaw/workspace/skills/diarybeast/.token printf '%s\n' "$ADDRESS" > ~/.openclaw/workspace/skills/diarybeast/.address ``` - Explicitly enforce permissions with `chmod 700` on the directory and `chmod 600` on the token file. - Prefer an operating-system credential store or agent-managed secret store instead of a plaintext file. - Remove the token immediately after expiration or logout. - Avoid printing the token in logs, command traces, diagnostics, or error reports. - Validate file ownership before reading a previously stored token and reject symbolic links or files owned by another account.