[Redacted] Multiple Web Application Security Bugs in your favorite Filipino or SEA e-Commerce site

Last 2018 up until now, this platform is considered to be one of the bigshots in the e-Commerce industry particularly here in the Philippines and the rest of Southeast Asia. Initially, I thought that such e-Commerce platform didn’t have a bug bounty program not until they were acquired by this startup ‘unicorn,’ thus, making it one of its assets/acquisitions. Even though such ‘unicorn’ didn’t include it yet in its bug bounty program scope, still, I thought of submitting my findings to them.


Here are the list of some of the vulnerabilities I found in it, along with its bounty rewards:

  • STORED XSS via Product Title field ($400)
  • STORED XSS via Shop Name field ($400)
  • STORED XSS by bypassing File Upload default filetypes($400)
  • STORED XSS via insertion on Multi-Clickable Banner’s URL ($300)
  • STORED XSS via Voucher Promotion’s Title and Description ($300)
  • STORED XSS via Free Style Feed ($300)
  • SSRF via coverURL param ($300)
  • OPEN REDIRECT via todo param ($100)
  • SSRF via Product Link field ($300)
  • SSRF via imageURL param ($300)
  • SSRF via freestyleImgUrl param ($160)
  • SSRF via coverURL param ($300)

The rewards given by such bug bounty program is based on their own range of bounty standard.


To those who don’t know yet, Stored XSS or Persistent Cross-Site Scripting vulnerability is considered to be the most impactful than the other types of XSSes. This is due to the fact that it is, by nature, self-contained and triggers the applied malicious scripts even without no user interaction. The impact towards the platform is significantly high also because the victims are already logged in (which might be prone to stealing of authenticated tokens), compared to Reflected XSS wherein the attacker still has to, somehow, assume that the victim user is currently logged in–thus, with a lower bug bounty reward.

As for Open Redirect, there are a lot utilizations for it. For two, it might be used in redirecting the victim user to a malicious site and/or it might be used to chain with other web application attacks such as CSRF or Account Takeover.

For SSRF or Server-Side Request Forgery, it might be used as means to execute unauthorized actions or perhaps fetch some data within the organization or company.

Further Notes

Since this is an e-Commerce platform, there are two user privileges that were identified here: The Seller and the Buyer. The Seller initiates the creation, edit, and deletion of the Shop along with its vouchers, products, promos, shop designs, you name it. The Seller can also be the Buyer. While the Buyer can only and primarily visit the shop, choose which products to ‘addutucartu’, and checkout. Note that the Buyer and the Seller have different user interfaces. The Seller needs to log in on the ‘main’ site, instead of the seller site, for him/her to buy some products.

One common thing that I did in all of these web application vulnerabilities is that equipping thy self with a “what if I became the evil seller here?” mentality. Instead of hunting for vulnerabilities on the Buyer’s end, which is commonly what others would do, I hunted and applied use cases via the Seller's perspective. Fuzzed and recon'd the platform all through out and for every endpoint, parameter, or field I could identify, I try to check the source code and its behavior if there's any form of user input sanitation implemented to it. If there's one, proceed to application of some bypasses. If there's none, proceed to exploitation. Likewise, the method of always keeping tabs with a checklist especially detailing which features, pages, endpoints, and/or fields are being displayed/accessible on the Buyer's end and what is not, also towards the Seller, how they are interconnected, and triggering factors--I took notes of all the things I could potentially simulate an 'attack' or place my payloads into. This resulted to the discovery of those findings.

Most of the findings I found in this platform are marked as High severity. If you were wondering why the bounty amount is only like that even if its mostly High in severity, it is due to their policies in place (Yep, I know, somehow low compared to others, but still, that’s some buck when you’re situated in the Philippines). Below are the range of bounty amounts for each severity:

  • Critical -> $900-1000
  • High / Important -> $300-400
  • Medium / Moderate -> $50-80
  • Low -> $15-30

In some cases, I targeted and only participated in bug bounty events in their platform wherein they double the given bounty range to increase the rewards. Hence, there were instances that I didn’t manage to escalate some findings and rather decided to submit it immediately such as the SSRF ones because I might be prone to duplicates knowing that other bug bounty hunters are actively looking for security bugs as well.

There are other findings that I didn’t only found through the powerhouse SEA e-Commerce platform, but also to other assets that the startup ‘unicorn’ owns. Overall, I found 45 security issues in their assets. That’s why it led me to be included in their Top 20 lineup of web application security researchers for 2018.