Business logic flaw: I can order anything from your account without paying for it.
In this writeup, I will share my first finding of an application logic flaw, which I found in a e-commerce platform provider (like Shopify).
The bug is not resolved yet, so let's call it example.com . So all the subdomains under *.example.com were in scope. As I recently started learning about logic related bugs, I started playing around with the main application.
The application lets you create your own shop. All the shop that you create goes under example.com/{shop-name} directory and you can control them from web.example.com . So my methodology here was to implement a feature as an admin and then try to exploit them as a normal user, implement a restriction as an admin, and try to bypass them with a low-privileged user, you got the point. So I created a basic store and started playing with it.
My first goal was to sniff out some IDORs. I fired up my proxy and started using the application like a normal user. I used every function, clicked every button, and then opened by burp history to check what kinda request it was sending, I saw some possible IDOR entry points such as /api/order/buyer/853f-42aa/order/ and /api/store/seller/1337 . So I thought of creating a 2nd account to test the possible IDORs, and from here the main story begins..
It was an OTP based authentication, I verified my second email and created an account. Then I logged in, only to find… an order already sitting in my My Orders section. Wait, what? I had just created the account, so why was there an order already there? Umm, interesting…
Turns out, during some unauthenticated testing earlier, I had placed an order and used my second email as the contact email during checkout.
So it created the account with the contact mail and handled the order through that account. My hacker sense started tingling.. I created an account with victim@email.address . In my second browser, I placed an order and in the checkout, I provided the victim@email.address as contact mail and BOOM! — The order was associated with the victim's account.
Backend Logic
When someone places an order, the application first checks, if the user is authenticated or not. If authenticated → handle the order through the authenticated account. If not authenticated → the application takes the contact mail from the checkout and checks if any account already exists with this email or not. If exists → associate the order with the existing account and handle through it. if doesn't exist → create an account with the contact mail then associate and handle the order through it.
The flaw in the logic
While handling an unauthenticated user’s order, the application takes the contact mail from the checkout and handles the order with it, but it doesn't check whether the user providing the contact mail actually owns the email address or not. As a result, An attacker can use the victim’s email address as a contact mail in the checkout to place an order from the victim’s account.
Escalation
There is a pointing feature in the control panel. If turned on, users will get certain points for specific amounts of spending as cashback, which they can use in later orders. If this feature is enabled in any shop, the attacker can use the same exploit steps and choose Purchase with points in the checkout to deal some big financial loss to the victim.
Suddenly I felt a superpower in my hands, I could order whatever I wanted without paying for it! or troll my friends by ordering them some weird t-shirts from their own account — If I were an attacker XD. I reported the issue immediately without further testing and now waiting for the bug to be fixed.
It was my first finding related to logical flaws and also my first ever writeup, lemme know your thoughts. Got questions? Hit me up on X and let's chat!
Until the next one, keep hacking!
