T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:18
- Finding
- Sensitive Twitter/X Session Credentials Are Collected and Transmitted Through Unsafe Channels## Vulnerability Details **File Location**: `SKILL.md:18-28`; duplicated verbatim in `README.md:18-28` **Vulnerability Type**: Sensitive credential exposure and insecure secret handling **Risk Level**: High **Relevant snippet (English translation of the documentation):** ```text 3. Configure in OpenClaw (strongly recommended): openclaw config set skills.entries.fapi-twitter.apiKey "<your complete API key>" openclaw config set skills.entries.fapi-twitter.auth_token "<your auth_token>" openclaw config set skills.entries.fapi-twitter.ct0 "<your optional ct0 value>" Or say directly in the chat: "My fapi API key is xxx, and my auth_token is yyy" Core request rules: 2. Every request must include: Authorization: Bearer {{apiKey}} 3. Most write operations require auth_token and ct0 parameters. ``` ### Technical Analysis The Skill instructs users to provide an fapi API key and a Twitter/X `auth_token`, either through OpenClaw configuration or directly in a chat message. It subsequently directs the agent to send these credentials to the third-party `fapi.uk` API. A Twitter/X `auth_token` is a sensitive session credential rather than a narrowly scoped application token. Depending on the session state and accompanying values such as `ct0`, disclosure can allow actions under the authenticated user's account. The advertised functions include creating tweets, replying, uploading media, following or unfollowing accounts, blocking users, accessing notifications, handling direct-message media, and account-related operations. Direct entry in chat can expose credentials through conversation history, telemetry, debugging output, model-provider logs, exports, or transcript synchronization. General configuration storage can similarly expose secrets through plaintext files, backups, broad file permissions, or diagnostic tooling. Transmitting the session credential to an intermediary also expands the trust bound ...[truncated 2141 chars]
- Remediation
- ## Remediation Suggestions 1. Replace raw Twitter/X session-cookie collection with an official OAuth authorization flow using narrowly scoped, revocable access tokens. 2. Never instruct users to paste API keys, `auth_token`, `ct0`, cookies, or other secrets into chat. 3. Store credentials in an operating-system-backed secret manager or the platform's dedicated encrypted credential store rather than ordinary configuration. 4. Ensure secrets are never included in prompts, transcripts, telemetry, exception messages, command history, or debug logs. Apply deterministic redaction to request headers and sensitive parameters. 5. Use separate, operation-specific permissions where possible. Read-only requests should not receive credentials capable of account-changing operations. 6. Require explicit user confirmation immediately before sensitive write operations such as posting, following, blocking, direct-message activity, account unlocking, or media uploads. 7. Document the third party's credential retention, encryption, access-control, deletion, incident-response, and subprocessors policies. 8. Provide token revocation and rotation instructions, and automatically invalidate credentials after suspected exposure. 9. Avoid passing secrets as command-line arguments because they may appear in shell history or process listings. Use protected interactive input or secret-store references. 10. Correct the inconsistent configuration entry names (`fapi-twitter` and `fapi-uk`) to reduce the risk of secrets being stored in unintended configuration locations.