Finding our first flaws in Trendsales and establishing contact with them

As curious people, and former sneaker bot developers we like to “poke” at website API’s and how they work, to try and see how the internet is designed and how it develops, it doesn’t really matter which site we’re exploring, we do it everywhere, and Trendsales was no exclusion.

While it isn’t everytime we check for bugs, we had heard from other people that there might be some various bugs on the site. But before we went on to test these claims, we contacted them (Trendsales) to ask if they had a bug bounty program, and if they did, we would like to participate in it. We were then put in contact with the CTO of Trendsales, where we discussed the possibility of a bug bounty program, and we were told that they didn’t have one, but they were interested in hearing about the bugs we had found.

We then went to town on testing the site, and this blog post will outline the first few bugs we found, and how we found them.

Everything we’re talking about has been patched, otherwise we wouldn’t write this :)

Deactivate other user’s listings (IDOR)

Now, we didn’t know where to start - this was our first time actually hunting for bugs, and hoping to be paid.

We started off by looking at the API for listings, especially creating and deleting them. We quickly found that we couldn’t create listings on other’s behalf, however, we could delete them. This was a huge issue, as we could delete other people’s listings, and we could do it without any form of authentication for the account we deleted listings from.

One of the critical vulnerabilities discovered within the API revolved around Broken Access Control (BAC) and Insecure Direct Object References (IDOR). This flaw enables authenticated users to deactivate any listing on the platform, regardless of ownership.

Technical Details: The vulnerability lies within the API endpoint /me/{user-profile-id}/active/{target-listing-id}, where insufficient checks fail to verify the correspondence between user-profile-id and target-listing-id. By exploiting this vulnerability using a crafted HTTP request, an attacker can systematically deactivate listings, thus an attacker could gain an advantage by removing competitors’ listings or causing financial damage to the platform.

Reflected XSS through Search Queries

Another thing we noticed was that search queries were appended in the URL, and we quickly found that we could inject HTML and JavaScript into the search query, and it would be reflected back to us. This was a huge issue, as we could use this to steal cookies, by sending hand-crafted URL’s to users and claiming it was legitimate search results.

The vulnerability was from the direct injection of the query parameter into the webpage’s <title> tag, allowing for script injection.

Stored XSS on Shop Descriptions

While the previous XSS was a reflected one, we also found a stored one. This was found in the product and shop descriptions, where we could store HTML and JavaScript, and it would be reflected back to us when we viewed the product or shop.

This worked by escaping the “Description” for an item, eg. by using the following payload:

”\\”/><svg / onl o ad=\ ’ +/\\”/+/onmouseover =1/+/[∗/[]/+ a l e r t (1)//\ ’> <\\”

This would then be reflected back to us when we viewed the product or shop, and the payload would be executed.

Missing Filetype Sanitation

Lastly, a concerning vulnerability was identified in the picture upload functionality of the Tradono API. The absence of proper filetype sanitation opens the door for potential exploitation, allowing unauthorized file uploads. In collaboration with the stored XSS, an attacker could upload a malicious file, and then use the stored XSS to execute the file, and gain access to the user’s cookies.

This issue was identified in the API endpoint /users/{ID}/pictureupload