| Title | macrozheng mall 1.0.3 Business Logic Errors / Improper Input Validation |
|---|
| Description | ## Vulnerability Description
The Alipay payment functionality in macrozheng/mall does not properly validate the payment amount against the authoritative amount of the corresponding order stored in the database.
The vulnerable payment flow is implemented in the `mall-portal` module, primarily involving:
* `com.macro.mall.portal.controller.AlipayController`
* `com.macro.mall.portal.service.impl.AlipayServiceImpl`
* `com.macro.mall.portal.service.impl.OmsPortalOrderServiceImpl`
In `AlipayServiceImpl.pay()`, the application constructs the Alipay payment request using values supplied through the client-controlled `AliPayParam` object. In particular, the `total_amount` field is obtained directly from `aliPayParam.getTotalAmount()` without querying the corresponding order and verifying that the supplied amount matches the order's actual `pay_amount`.
Conceptually, the vulnerable logic is:
```java
bizContent.put("out_trade_no", aliPayParam.getOutTradeNo());
bizContent.put("total_amount", aliPayParam.getTotalAmount());
bizContent.put("subject", aliPayParam.getSubject());
```
The application therefore trusts a client-controlled payment amount instead of deriving the amount from the server-side order record.
The payment-success flow contains an additional validation weakness. `OmsPortalOrderServiceImpl.paySuccessByOrderSn()` locates an unpaid order using only the supplied order number:
```java
example.createCriteria()
.andOrderSnEqualTo(orderSn)
.andStatusEqualTo(0)
.andDeleteStatusEqualTo(0);
```
No verification is performed to ensure that the order belongs to the current user, and no verification is performed against the amount actually paid.
Furthermore, `AlipayServiceImpl.query()` invokes `paySuccessByOrderSn()` after receiving a successful Alipay transaction status, but the actual payment amount returned by Alipay is not compared with the order's expected `pay_amount`.
As a result, the invariant that the amount actually paid must equal the amount owed for the order is not enforced by the payment flow.
### Proof of Concept
The vulnerability was verified using the Alipay Sandbox environment.
No real payment or real financial transaction was involved. The test order
was created specifically for security testing.
https://open.alipay.com/develop/sandbox
A legitimate unpaid order was created with the following properties:
* `order_sn`: `202609010000000001`
* `pay_amount`: `1000.00`
* `status`: `0`
* SKU stock ID: `98`
* Initial stock: `86`
The payment endpoint was then accessed with a manipulated amount:
```http
GET /alipay/pay?outTradeNo=202609010000000001&subject=test&totalAmount=0.01
```
The endpoint returned HTTP 200 and generated an Alipay payment form containing the following `biz_content`:
```json
{
"out_trade_no": "202609010000000001",
"total_amount": 0.01,
"subject": "test",
"product_code": "FAST_INSTANT_TRADE_PAY"
}
```
The original order amount of `1000.00` was not used when constructing the payment request.
The payment was then completed through the Alipay sandbox using an attacker-controlled test account with a payment amount of `0.01`.
After the low-value payment was completed, the following request was issued:
```http
GET /alipay/query?outTradeNo=202609010000000001
```
The server returned:
```json
{
"code": 200,
"message": "操作成功",
"data": "TRADE_SUCCESS"
}
```
The resulting database state was verified as follows:
| Data | Before | After |
| -------------------------- | -----------: | --------------------: |
| `oms_order.status` | `0` (unpaid) | `1` (paid) |
| `oms_order.payment_time` | `NULL` | `2026-09-01 11:38:02` |
| `pms_sku_stock.stock` | `86` | `85` |
| `pms_sku_stock.lock_stock` | `-24` | `-25` |
Therefore, an order with a real payable amount of `1000.00` was accepted as paid after only `0.01` was transferred, and the normal payment-success business logic was executed, including inventory modification.
### Impact
Successful exploitation allows an attacker to manipulate the amount charged for an order and potentially purchase goods for an arbitrarily reduced price, resulting in direct financial loss to the application operator.
The vulnerability also affects order-state integrity because the payment-success handler changes an unpaid order to the paid state without verifying that the amount actually paid matches the order amount.
The payment-success operation additionally triggers inventory updates, meaning exploitation can cause unauthorized changes to stock-related data.
The affected payment endpoints are also exposed without authentication according to the application's `/alipay/**` security whitelist, further increasing the attack surface.
|
|---|
| Source | ⚠️ https://github.com/macrozheng/mall/issues/998 |
|---|
| User | mjh_123 (UID 92618) |
|---|
| Submission | 09/04/2026 04:47 (1 month ago) |
|---|
| Moderation | 10/11/2026 10:29 (1 month later) |
|---|
| Status | Accepted |
|---|
| VulDB entry | 416563 [macrozheng mall up to 1.0.3 Payment Endpoint AlipayServiceImpl.java AlipayServiceImpl.pay total_amount logic error] |
|---|
| Points | 20 |
|---|