T09 · Insecure Skill Coding Practices
Warning
- Location
- references/1-商户/示例代码/2-代扣扣款/申请扣款.md:40
- Finding
- Plaintext HTTP Callback Endpoints Are Permitted and Demonstrated<![CDATA[ ## Vulnerability Details **File Locations**: - `references/1-商户/接入指南/回调处理.md:27-30` - `references/2-服务商/接入指南/回调处理.md:29` - `references/1-商户/示例代码/1-用户签约/公众号纯签约.md:31` - `references/1-商户/示例代码/2-代扣扣款/申请扣款.md:40` - `references/2-服务商/接入指南/签名与验签规则.md:71,83,120` - `references/2-服务商/示例代码/2-代扣扣款/申请扣款.md:40` **Vulnerability Type**: Transmission of payment callback data over an unencrypted channel **Risk Level**: Medium ### Vulnerable Code The direct-merchant deduction example uses a plaintext callback endpoint: ```xml <notify_url>http://yoursite.com/wxpay.html</notify_url> ``` The service-provider deduction example contains the same insecure pattern: ```xml <notify_url>http://yoursite.com/wxpay.html</notify_url> ``` The callback guidance also explicitly permits callback URLs beginning with either HTTP or HTTPS rather than requiring HTTPS. ### Technical Analysis The Skill permits and repeatedly demonstrates unencrypted HTTP callback endpoints for financial agreement and deduction-result workflows. A developer following these stored examples may deploy a payment callback handler without transport-layer encryption. HTTP provides neither confidentiality nor transport integrity. An attacker positioned between WeChat Pay and the merchant endpoint could observe callback metadata, block callbacks, delay delivery, or replay captured requests. Proper V2 signature verification limits the attacker's ability to create or arbitrarily modify a valid signed callback, but it does not prevent disclosure, traffic analysis, denial of service, or replay of an authentic captured message. The risk is amplified because the Skill instructs the agent to retrieve and display stored examples rather than generate corrected implementations. Users may therefore copy the plaintext callback URL directly into an integration. ### Attack Path 1. A merchant requests a deduction or callback integration example from the Skill. 2. The Skill displays the stored example containing an `http:/ ...[truncated 1252 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require HTTPS for every public payment, agreement, refund, and deduction callback endpoint. 2. Replace every `http://` callback example with an `https://` example. 3. Update the callback guidance so that HTTPS is mandatory rather than presenting HTTP and HTTPS as equivalent options. 4. Require valid certificate-chain and hostname verification. Do not permit disabled TLS verification or self-signed certificates in production. 5. Continue verifying the V2 signature before parsing or acting on callback business fields. 6. Enforce replay and idempotency controls using the relevant transaction identifier, merchant order number, event type, and locally recorded processing state. 7. Compare callback amounts and merchant identifiers against authoritative local order records. 8. Return success only after durable, idempotent state processing has completed. 9. Use order-query and reconciliation workflows to recover from callbacks that are delayed, blocked, or lost. 10. Add a prominent warning that sample domains and callback URLs are placeholders and must not be copied unchanged into production. ]]>