Submit #708175: youlai-mall latest Improper Control of Resource Identifiersinfo

Titelyoulai-mall latest Improper Control of Resource Identifiers
Beschreibung## Contributors: Huang Weigang ### 1. Vulnerability Impact youlai-mall (latest) https://github.com/youlaitech/youlai-mall ### 2. Vulnerability Location - orderSn: POST /mall-oms/app-api/v1/orders/payment ### 3. Code Analysis - Controller: mall-oms/oms-boot/src/main/java/com/youlai/mall/oms/controller/app/OrderController.java - @PostMapping("/payment") → orderService.payOrder(paymentForm) - Service: mall-oms/oms-boot/src/main/java/com/youlai/mall/oms/service/app/impl/OrderServiceImpl.java - payOrder(OrderPaymentForm) : loads order by orderSn , checks only UNPAID , no ownership check ( order.getMemberId() == SecurityUtils.getMemberId() missing). - Balance path: balancePay(order) deducts the order owner’s balance: - Long memberId = order.getMemberId(); - memberFeignClient.deductBalance(memberId, order.getPaymentAmount()); - Then deducts stock and updates order status to PAID . - WeChat path: wxJsapiPay(appId, orderSn, paymentAmount) uses the current user’s openid (via SecurityUtils.getMemberId() ), still without verifying that the payer owns the order. ### Vulnerability Reproduction - Preconditions - Attacker has a valid App login token ( Authorization: Bearer <token> ). - Target user’s orderSn is known or guessable (e.g., via UI, logs, or predictable numbering). - The order is in UNPAID status. - Target Endpoint - POST /mall-oms/app-api/v1/orders/payment - Steps (drain another user’s balance by paying their order) - Log in as User A and obtain a valid token. - Use User B’s orderSn and set payment method to balance: - curl -X POST "https://<gateway>/mall-oms/app-api/v1/orders/payment" -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d '{"orderSn":"ORDER12345","paymentMethod":"BALANCE"}' - Observe 200 OK and a success response, for example: - {"code":200,"data":true,"msg":"success"} - Outcome: the order (owned by User B) is marked as paid and User B’s balance is deducted; User A’s ownership is never verified. ### 4. Impact Description - - Unauthorized fund deduction - Any logged-in user can trigger payment on another user’s order using the victim’s balance, causing direct monetary loss and violating account boundaries. - Horizontal privilege escalation - Ownership is never validated; possession of orderSn suffices to change financial state of another user’s account, breaking least-privilege principles. - Attack scalability - If orderSn values are predictable or enumerable, attackers can automate draining balances across many accounts and orders. - Business and compliance risk - Unapproved financial operations undermine reconciliation, audit, and customer trust; lack of rate limits, idempotency, and audit trails increases regulatory exposure. - Attack chain amplification - Combined with other horizontally vulnerable App endpoints (e.g., GET /members/{memberId}/openid , GET /members/{memberId}/addresses ), attackers can target specific users more effectively and inflict larger coordinated damage.
Quelle⚠️ https://github.com/Hwwg/cve/issues/26
Benutzer
 huangweigang (UID 88993)
Einreichung07.12.2025 07:02 (vor 6 Monaten)
Moderieren25.12.2025 10:50 (18 days later)
StatusAkzeptiert
VulDB Eintrag338413 [youlaitech youlai-mall 1.0.0/2.0.0 Balance MemberController.java deductBalance erweiterte Rechte]
Punkte20

Do you want to use VulDB in your project?

Use the official API to access entries easily!