So, this story is about two bugs I found in a single day, both within the same target. Both bugs are located in the same feature. Let’s dive into the story from the beginning.

Target Information:

So, for the sake of company privacy, let’s refer to it as target.com. All subdomains are within the scope, i.e., *.target.com. The main focus of the company is to provide various services to other companies, including project collaboration features and software solutions for efficient work.

Recon Phase:

So, usually, I kick off my recon by running a custom bash script that executes multiple tools in a specific order. After gathering all the subdomains, one subdomain caught my attention i.e swag.target.com. This subdomain hosts the company’s merchandise that anyone can purchase. So, I thought to test this subdomain because this is not the main focus of company so this can be a little bit ignored. And guess what ? I was right .

1st Bug:

So , I started checking all the features of this website . While attempting to add an item to my cart, I observed that it was assigned an ID, indicating that each cart may be associated with a unique identifier. The request appeared as follows -

POST /product/add/{cart_id}
[[body]]
product_id={any_product_id}&token=your_token

So, I attempted to add another item to my cart and intercepted the request using Burp Suite. I then modified the cart ID in the request to match the cart ID of my second account and the product was successfully added to my second account’s cart.

So, this entire scenario indicates that I could add products to anyone’s cart. However, there was a limitation on the number of products that could be added to a cart, preventing me from adding an excessive amount of products to someone else’s cart.

This issue got accepted as medium severity and I got a reward of $300 for this.

2nd Bug:

This second issue is about information disclosure. After placing an order, we are required to provide primary contact information, such as a phone number or email address.

So on checking my primary contact details there was an endpoint like -

GET /order/details/primary?orderID=your_order_id

This endpoint will display the primary contact information associated with your order, which can be either your email or phone number. It also shows the item you have ordered. However, if you modify the orderID to another person’s orderID, you will be able to view their primary contact information along with the product they have ordered.

Finally , I tried to change this endpoint a little bit to get more sensitive data like address , etc but failed to do so .

Now, I submitted the above mentioned issue as a “primary contact information leak”. The issue was once again accepted as medium severity since it only exposed the email/phone-number of the receiver. Although the orderID could be brute-forced, it would still require a considerable amount of time for successful exploitation. As a reward for this issue, I received $500.

I hope you are able to learn something new with this . Follow me for more such informational content .