| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Business Logic — Integer Overflow / 32-bit Signed Wrap |
| Difficulty | Practitioner |
| Objective | Exploit an integer overflow in the purchasing workflow to buy the "Lightweight l33t leather jacket" |
Low-Level Logic Flaw¶
I logged in as wiener:peter and added the jacket to the cart:
Probing the quantity field: quantity=-2 emptied the cart — negative quantities rejected at input.
quantity=100 returned "Invalid parameter: quantity."
quantity=90 went through — 99 appears to be the per-request max.
The quantity field caps at 99 and rejects negatives, but the server likely accumulates the cart total in a 32-bit signed integer. 32-bit signed integers max out at 2,147,483,647 — exceeding that wraps the value to a large negative number. Adding positive quantities indefinitely achieves the same effect as a negative balance, just through overflow rather than directly. The 99-per-request cap doesn't prevent this; it just means more requests are needed to trigger it.
I sent the add-to-cart request to Intruder with null payloads on continuous repeat and a single concurrent request, then watched the cart total in the browser climb until it wrapped negative:
With the total at -$8,214,297.92, I used the price and max quantity to estimate how many more batches were needed to push toward $0, then iterated in decreasing batch sizes — 62 more, then 20, then 5, then single requests to close in:
The overflow doesn't give a precise landing point — just a general direction. Fine-tuning the total to land within $0–$100 required adding cheap filler products to adjust the final value:
After several adjustments, the cart landed within store credit range. Placing the order:
Lightweight "l33t" Leather Jacket $1337.00 160410
Cheshire Cat Grin $84.51 3315
Six Pack Beer Belt $13.98 4
And lab solved