T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:71
- Finding
- Weak Knowledge-Based Verification Allows Unauthorized Policy Information Disclosure## Vulnerability Details **File Location**: `SKILL.md`, lines 71 and 160-175 **Vulnerability Type**: Weak identity verification and sensitive information disclosure **Risk Level**: High ### Vulnerable Code Snippet ```python "保单查询": { "典型说法": ["我的保单", "保到什么时候", "保额多少"], "路由": "模块1 保单查询", "必核要素": ["姓名", "证件号后四位", "手机号"], "风险提示": "未完成身份核验不得展示保额与受益人" } ``` ```text 客户：我想查一下我的保单 客服：为保障您的信息安全，需要先核验身份。请提供投保人姓名、 身份证号后四位，以及预留手机号后四位。 客户：张伟，身份证后四位 1234，手机后四位 5678 客服：核验通过。您名下有效保单共 2 张： 1）国联人寿「医惠锡城」2026 版 —— 保至 2027-06-30 2）国联人寿定期寿险 —— 保至 2035-03-31 请问您要查看哪一张的详细信息？ 客户：第一张 客服：【保单号】POL-000001 【产品名称】医惠锡城 2026 版 【生效/到期】2026-07-01 至 2027-06-30 【当前状态】有效 【保障概要】住院医疗费用、特定药品费用（具体责任以条款为准） ``` ### Technical Analysis The Skill treats a customer name, the last four digits of an identity number, and the last four digits of a registered phone number as sufficient verification before disclosing policy information. These values are static knowledge factors rather than proof of identity or possession. Partial identity and telephone data may be obtained from leaked datasets, documents, prior communications, social engineering, or people acquainted with the victim. Matching these values does not establish that the requester controls the registered communication channel or has authorization from the policyholder. After this weak verification, the example discloses the existence and number of policies, product names, insurers, coverage periods, policy status, policy number, and coverage summary. Insurance holdings can also reveal financial or health-related information. ### Attack Path 1. An attacker obtains a victim's name, identity-number suffix, and phone-number suffix from a leak, document, or social-engineering interaction. 2. The attacker initiates a policy inquiry while impersonating the victim. 3. The attacker supplies the static values requested by the Skill. 4. The workflow considers verification successful without ...[truncated 784 chars]
- Remediation
- ## Remediation Suggestions 1. Replace static knowledge-based verification with a server-validated possession factor, such as a one-time code sent to the registered phone, an authenticated official application session, or an equivalent strong authentication mechanism. 2. Do not disclose whether a policy exists until authentication and authorization have both succeeded. 3. Bind successful verification to a short-lived session and require renewed verification before displaying especially sensitive fields. 4. Apply attempt limits, rate limiting, temporary lockouts, anomaly detection, and security logging to verification requests. 5. Use generic failure messages that do not reveal which submitted identifier was correct. 6. Require documented authorization for representatives or family members and verify both the authorization and representative identity. 7. Minimize post-authentication disclosure according to the customer's request and role. 8. Add automated tests confirming that policy counts, identifiers, coverage details, and status cannot be returned before strong verification succeeds.