Multiple Vulnerabilities on E-Commerce (Password Reset + 3 IDORs)

Hello, In this writeup I’m going to talk about multiple vulnerabilities I found on ecommerce.com, an e-commerce app for used products where users can add items to cart, buy them, or bid on live auctions.
in this writeup i have 4 bugs: one password reset token issue, and three different IDORs

Target:
let’s call our target ecommerce.com

Bug 1: Password Reset Token Doesn’t Expire

i started testing the main auth functions: sign-in, sign-up, password reset, and OAuth
while testing password reset i noticed something interesting, the reset token doesn’t expire until a new one is requested
so i decided to dig deeper, i changed the email address on one of my test accounts, then tried to use the OLD reset token again
and guess what? it worked!

Attack Scenario

so i built a realistic scenario out of this:

• victim creates an account, and receives a reset/create password link on their registered email
• victim changes their email to a new one (e.g from victim@old.com to victim@new.com)
• attacker, who already has access to victim@old.com, still has the old reset link
• attacker uses that old link to reset the password
• attacker successfully takes over the victim’s account

at first i thought they would close it as informative/N-A, but they accepted it as Low severity, the scenario was realistic enough to make sense to them

Bug 2: Cancel Any User’s Purchase via IDOR

after a couple of days i moved to testing other functions: add to cart, complete order, and view purchases

how the purchase flow works

• user adds a product to cart
• user clicks complete order
• the product moves to the purchases list, and the user has to pay for it, otherwise the account could get blocked for having uncommitted purchases

  Discovery

  before payment, a POST request is sent to

  /api/webapi/shopping/ordercheckout/createuncommittedpurchaseorder
  

  this marks the order as uncommitted until payment happens
  if this request is sent more than once:

• the purchase disappears from the account, so it can’t be paid for later
• after a while, the account gets blocked for having too many uncommitted purchases
  so i created an order on my second account and replaced the purchaseOrderId with the one belonging to the first account
  and it worked, i canceled the other account’s purchase

  Bypassing the GUID/UUID Policy

  but there was a catch, the program’s policy states that any IDOR depending on a GUID/UUID gets downgraded to Low severity
  so i challenged myself to find something better
  i crawled the site, went through the purchasing flow as a regular user, and checked my Burp history
  i searched for purchaseOrderId and found another vulnerable parameter tied to it
  how i got the purchaseOrderId:
  when you attempt to purchase a product, a transactionId is generated and tied to the purchaseOrderId, when completing the purchase, the app sends a GET request with the transactionId to retrieve the purchaseOrderId, then uses it to complete the process

  Attack Scenario

• write a simple python script (or use Burp Intruder) to brute force valid transactionId values (0 to 999999999)
• retrieve all corresponding purchaseOrderIds
• uncommit/cancel any purchase order on ecommerce.com, for any user

  Impact

• attacker can cancel any purchase for any user without their knowledge
• attacker can spam this behavior to get random users’ accounts blocked
  i initially thought account blocking was fully automated based on uncommitted purchases, but the team clarified it’s controlled manually on their end

  Result

  we reported this as Critical, they accepted it as Medium, still a solid finding
  

Bug 3: IDOR via cartId Allows Viewing/Modifying Victim’s Cart

while testing the cart functionality i noticed the cartId parameter is trusted without checking who actually owns it

Attack Scenario

• attacker has the victim’s cartId
• attacker performs a normal action on their own cart (add, remove, or view), intercepting the request with Burp Suite and sending it to Repeater
• attacker replaces their own cartId in the intercepted request with the victim’s cartId
• attacker successfully adds to, removes from, or views the contents of the victim’s cart by sending the modified request

  Impact

• attacker can view a victim’s private cart contents
• attacker can add unwanted items or remove items from a victim’s cart without their knowledge
  

Bug 4: IDOR on /cartoverview/ Endpoint

i found another related issue on a different endpoint that handles cart overview, /api/webapi/shopping/checkout/cartoverview/<cartId>, it has improper access control checks on the cart identifier
Same impact as Bug 3, and it was also a duplicate.
I hope you enjoyed my writeup — see you soon!
—