Infinite money logic flaw

The Infinite Money Logic Flaw is a business logic vulnerability that allows an attacker to generate unlimited store credit by abusing the interaction between the application’s discount system and gift card functionality. Unlike common technical vulnerabilities such as SQL injection or broken authentication, this issue arises because individually legitimate features interact in an unintended way. The application allows users to purchase gift cards, apply discount coupons to reduce the purchase price, and later redeem those gift cards at full value. Because the redemption value is greater than the discounted purchase cost, the attacker can generate profit from each cycle and repeat the process indefinitely.

The attack begins when the user logs into the application and signs up for the newsletter. As part of the signup process, the application provides a promotional coupon code:

SIGNUP30

This coupon grants a 30% discount on purchases. Normally, such coupons are meant to encourage product sales. However, the application fails to restrict its use on gift cards, which are effectively cash equivalents. This is the first major design flaw because gift cards should not be treated the same way as regular merchandise when discounts are involved.

During exploration of the application’s store, it becomes apparent that users can purchase $10 gift cards. These gift cards can later be redeemed from the “My account” page in exchange for store credit. This creates a closed financial loop:

Store Credit → Buy Gift Card → Redeem Gift Card → Store Credit

Under secure business logic, this loop should not generate profit. At best, the user should break even. However, because the application allows a coupon to reduce the cost of the gift card while preserving its full redemption value, each cycle increases the attacker’s available balance.

To exploit this manually, the attacker adds a gift card to the basket using a request such as:

POST /cart

The attacker then applies the coupon code through:

POST /cart/coupon

and completes the purchase using:

POST /cart/checkout

At checkout, the 30% discount reduces the price of the $10 gift card to $7. This means the attacker spends only $7 in store credit but receives a gift card that still holds its full $10 face value. This creates an immediate profit of $3.

After the purchase is completed, the application redirects to an order confirmation page:

GET /cart/order-confirmation?order-confirmed=true

This page displays the generated gift card code. The attacker copies this code and navigates to the account page, where gift cards can be redeemed by submitting a request such as:

POST /gift-card

with the parameter:

gift-card=ABCD-EFGH-IJKL

Once redeemed, the application credits the user with the full $10. Since only $7 was spent, the account balance increases by $3.

This confirms the presence of the infinite money condition. If the user starts with:

$100

then after one cycle they have:

$103

After ten cycles:

$130

The process can be repeated indefinitely to generate unlimited store credit.

Manually repeating this process is inefficient, so the attack can be automated using Burp Suite Intruder and Session Handling Rules. By analyzing Burp’s Proxy History, the attacker identifies the exact request sequence required to complete one profitable cycle:

POST /cart
POST /cart/coupon
POST /cart/checkout
GET /cart/order-confirmation?order-confirmed=true
POST /gift-card

To automate this workflow, the attacker creates a macro in Burp Suite under:

Settings → Sessions

The macro replays the entire sequence automatically. However, because each purchased gift card generates a unique code, the macro must dynamically extract the code from the response of:

GET /cart/order-confirmation?order-confirmed=true

Burp allows this by creating a custom parameter called:

gift-card

and highlighting the generated code in the response body.

The final request in the macro:

POST /gift-card

is then configured so that its gift-card parameter is automatically populated using the extracted value from the prior response. This ensures each purchased gift card is redeemed immediately after creation.

Once the macro is tested and confirmed to work, the attacker sends a request such as:

GET /my-account

to Burp Intruder. A Sniper attack is selected with Null payloads, meaning the request is repeated without modifying any parameters. The payload count is configured to generate 412 payloads, which repeats the macro enough times to accumulate a large amount of store credit.

To avoid race conditions or transaction failures, the attack is placed in a resource pool with:

Maximum concurrent requests = 1

This ensures each cycle completes successfully before the next begins.

As Intruder runs, the application repeatedly executes the profitable cycle:

purchase discounted gift card
extract generated code
redeem code for full value
increase store credit

Eventually, the attacker accumulates enough credit to purchase the expensive leather jacket and solve the lab.

The root cause of this vulnerability is poor enforcement of business rules. The application fails to consider the interaction between multiple financial features. The discount system incorrectly applies promotional discounts to gift cards, the purchase logic treats gift cards as normal products, and the redemption logic grants full face value regardless of the purchase price. Individually, each system works correctly, but together they create an exploitable financial loop.

In a real-world environment, this vulnerability could lead to severe financial losses. Attackers could generate unlimited account balances, purchase expensive products for free, or automate the exploit at scale. Businesses could suffer inventory loss and fraudulent transactions in a very short time.

A secure implementation should prevent discounts from being applied to gift card purchases. Alternatively, gift cards should only redeem for the amount actually paid rather than their face value. Fraud detection systems should also identify repeated purchase-redemption loops and flag suspicious activity.

This vulnerability demonstrates that application security is not only about preventing technical exploits, but also about understanding how legitimate features interact. Even when every feature works as designed, flawed business logic can create unintended exploit paths capable of causing significant damage.