To establish a testing environment, you can use a Docker container. The following commands will pull and run the latest image of a pre-configured Damicms instance.

docker pull betsy0/pwdflielogic:latest
docker run -d -p 10001:81 --restart always betsy0/pwdflielogic:latest

Risks Associated with Payment Vulnerabilities

Payment-related vulnerabilities typically involve the manipulation of transaction values. These can include purchasing multiple items for the price of one, acquiring goods for zero cost, or paying a price significantly lower than the listed amount, leading to direct financial loss for the business.

Common Testing Strategies for Payment Flaws

1. Altering Item Quantity: Modify the quantity parameter during payment to purchase multiple units for the price of one.
2. Using Negative Price Values: Set product prices to negative numbers to artificially increase account credit.
3. Modifying Payment Amount: Directly alter the price parameter submitted to the payment endpoint.
4. Switching Product Identifiers: Change the product ID in the request to substitute a high-value item with a low-value one.
5. Bypassing Payment Status: Manipulate status flags to mark unpaid orders as completed.
6. Interceptign Payment Interfaces: Exploit weaknesses in the payment gateway integration or order processing workflow.

Vulnerability Demonstration

First, register and log into the system. Upon checking, the account balance is zero. Selecting a product priced at 5400 units should normally be blocked due to insufficient funds. To analyze the transaction, we intercept the HTTP request.

Analyzing the Original Request

When proceeding to checkout, a POST request is sent to /index.php?s=/member/dobuy.html. The relevant parameters in the request body include:

• id[]: Product identifier.
• name[]: Product name.
• price[]: Product price.
• qty[]: Quantity of items.

An example request snippet is shown below:

POST /index.php?s=/member/dobuy.html HTTP/1.1
Host: 192.168.174.147:10001
Content-Type: application/x-www-form-urlencoded

id%5B%5D=69&price%5B%5D=5400&qty%5B%5D=1&...other_parameters

Exploiting Quantity Parameter Validation

A key area for testing is the quantity and price parameters. The server may not properly validate negative quantities. By changing the qty[] parameter to -10, the total charge becomes 5400 * (-10) = -54000. If the server blindly applies this to the user's balance, it could result in a credit increase.

We modify the intercepted request:

POST /index.php?s=/member/dobuy.html HTTP/1.1
Host: 192.168.174.147:10001
Content-Type: application/x-www-form-urlencoded

id%5B%5D=69&price%5B%5D=5400&qty%5B%5D=-10&...other_parameters

After submitting this modified request, the order is processed successfully. Checking the account reveals the balance has increased to 54000, confirming a logic flaw where negative quantities can inflate user funds.

Testing for Price Substitution Vulnerability

Another common test is attempting to purchase a high-priced item by submitting a lower price. For instance, item ID 127 is valued at 6000, while item ID 66 costs 4000. We attempt to buy item 127 but send the price for item 66.

We capture the request for the cheaper item and alter the product ID:

POST /index.php?s=/member/dobuy.html HTTP/1.1
Host: 192.168.174.147:10001
Content-Type: application/x-www-form-urlencoded

id%5B%5D=127&price%5B%5D=4000&qty%5B%5D=1&...other_parameters

In this instance, the order is created, but the system correctly associates the price from its backend database with product ID 127, resulting in a failed payment due to insufficient funds. This indicates the specific vulnerability of client-side price substitution is not present.

Recommended Mitigations

1. Obfuscate Sensitive Data: Transmit critical parameters like price and product IDs using encrypted or signed values instead of plain text.
2. Implement Server-Side Validation: Rigorously validate and sanitize all user-submitted parameters, including checking for negative values, non-numeric inputs, and quantity bounds.
3. Enforce Data Consistency: During order processing, verify submitted prices against the authoritative values stored in the database.
4. Validate Calculation Inputs: Ensure all numerical values involved in financial calculations (quantity, unit price) are positive integers before processing.
5. Utilize Digital Signautres: Generate a cryptographic signature for the entire order, including the final calculated amount. Verify this signature on the server before finalizing the transaction to prevent tampering.