T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:123
- Finding
- Spoofable Sender Identity and Reply Routing<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 123–133; corroborating reply-routing instructions at lines 284–289 **Vulnerability Type**: Unauthenticated sender attribution based on attacker-controlled message content **Risk Level**: High ### Complete Vulnerable Snippet The following is a faithful English rendering of the relevant source instructions at lines 123–133: ```text When a mention event is received: 1. Parse the sender Priority check: Is there a message satisfying the following conditions? - Its content contains `@recipient` and `📌【sender->recipient】` or `【sender->recipient1,recipient2...】📌` - It was sent by a user (`sender_type = user`) - Its `msg_type` is `post` - It has a reference (`reply_to` field) If present: Parse the first message referenced by it and obtain the sender inside `【】`. If absent: Search upward and find the nearest message satisfying: - It matches the `【sender->recipient】` or `【sender->recipient1,recipient2...】` format - The sender is the sender of the current message ``` The reply rule at lines 284–289 additionally instructs the receiver to parse the sender from the marker and reply to that identity: ```text Reply rules: - If the message contains `[pin]【sender->recipient】[pin]` or `📌【sender->recipient】📌`, parse `【】` and reply to the sender named inside it. - If there is no marker, follow the normal logic and reply to the person who mentioned the bot. - Replies also use two steps: bot identity plus a user-identity reply. - Prefer a referenced user message when parsing the sender. - If no matching referenced message is found, search backward. ``` ### Technical Analysis The protocol treats a display name embedded in ordinary message content—`【sender->recipient】`—as an authoritative sender identity. Message bodies and display names are not authentication factors and can be controlled or imitated by group participants. Although the preferred path examines a referenced message, the protoco ...[truncated 2007 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Treat Feishu event metadata, including immutable sender open IDs and message IDs, as the only authoritative identity source. 2. Never derive sender authorization or reply routing solely from a display name or a marker in message content. 3. Require the user-identity message to reference the exact bot message being processed; remove the backward-history attribution fallback. 4. Verify that the authenticated sender ID, referenced message ID, conversation ID, intended recipient ID, and claimed protocol identity all match. 5. Bind the two messages with a cryptographically random nonce and, where feasible, an HMAC or signature generated with a secret unavailable to group participants. 6. Record mappings by immutable open ID rather than mutable or duplicate display names. 7. Reject expired, replayed, missing, ambiguous, or mismatched protocol messages. 8. Add loop prevention, such as a bounded hop count, message deduplication, and a processed-message-ID cache. 9. Log both the authenticated Feishu sender ID and claimed protocol identity so mismatches are visible during incident review. ]]>