When hunting in programs that have been active for years, many researchers fear "duplicates." However, bugs often hide in specific functional workflows that others might overlook. Today, I'll share how I found a simple but impactful IDOR vulnerability on a well-established e-ommerce site.

The Strategy: Understanding the Flow

I spent 1–2 hours just browsing target.com without sending complex payloads. My goal was simple: Understand how the business logic works. After testing price manipulation and common business logic flaws without success, I decided to test the Return & Refund system.

The Discovery: Intercepting the Return Request

I made a legitimate purchase and then initiated a return request while the order was still in the "preparation" phase. When I clicked the return button, I intercepted the following request: https://www.target.com/return/rorderID=1123

The Attack: Disrupting the Refund Process

I noticed the rorderID was a simple integer. I quickly tested the previous IDs:

  • .../return/rorderID=1122
  • .../return/rorderID=1121

The Result: I successfully accessed the return pages of other users. While I couldn't see their private PII (Personally Identifiable Information), the page gave me a critical option: "Cancel Refund Request."

By simply changing the ID, I could cancel any user's refund, preventing them from getting their money back. This is a classic example of an IDOR leading to unauthorized functional manipulation.

Conclusion & Reward

I reported the finding immediately. Despite the program being two years old, this specific endpoint had been overlooked.

  • Timeline: Reported and accepted within 24 hours.
  • Bounty: $$$.

Stay Connected