T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:124
- Finding
- Alipay Callback Marks Orders as Paid Without Signature Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 124-131 **Vulnerability Type**: Unauthenticated payment callback processing **Risk Level**: Critical ### Vulnerable Code ```java @PostMapping("/ali-callback") public String aliPayCallback(HttpServletRequest request) { Map<String, String> params = getParams(request); if (TradeStatus.SUCCESS.name().equals(params.get("trade_status"))) { String orderId = params.get("out_trade_no"); orderService.updatePaid(orderId); } return "success"; } ``` ### Technical Analysis The callback trusts the caller-controlled `trade_status` and `out_trade_no` parameters. It changes the local order state without first verifying the Alipay signature. Checking that `trade_status` equals `SUCCESS` does not authenticate the notification because any HTTP client can supply that value. The example also does not validate the notification's application ID, seller identity, transaction amount, currency, or correspondence with a pending server-side order. Although a later section contains a signature-verification example, the earlier code is presented as a complete payment controller and can be copied independently. ### Attack Path 1. An attacker discovers or predicts a valid pending order ID. 2. The attacker sends a direct POST request to `/api/pay/ali-callback`. 3. The request contains `trade_status=SUCCESS` and the target order ID as `out_trade_no`. 4. The endpoint accepts these values without authenticating the sender. 5. `orderService.updatePaid(orderId)` marks the unpaid order as paid. 6. Any fulfillment process triggered by the paid state may release goods or services without a real payment. ### Impact Assessment A remote unauthenticated attacker may forge successful payment notifications and change the state of accessible or predictable orders. The resulting scope depends on downstream business logic and may include unauthorized fulfillment, financial loss, accounting inconsisten ...[truncated 51 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Remove the unsigned callback example so it cannot be copied into production. - Verify the Alipay signature with the configured Alipay public key before reading or acting on notification fields. - Reject notifications with an unexpected application ID, seller ID, encoding, or signature algorithm. - Load the order from trusted server-side storage and compare the notified amount and currency with the expected values. - Accept only valid state transitions from a pending order. - Store and enforce uniqueness for the Alipay transaction ID. - Perform the order-state transition atomically and idempotently. - Return `success` only after the authenticated event has been safely recorded. ]]>
