Exploiting an IDOR Vulnerability in Target.com Account Management System
Introduction
During a security assessment of Target.com account management system, I discovered a critical Insecure Direct Object Reference (IDOR) vulnerability. By manipulating user IDs in API requests, I was able to access sensitive information belonging to other users. The issue was exacerbated by a lack of proper Cross-Site Request Forgery (CSRF) validation and predictable user ID patterns. After thorough testing, I reported the vulnerability, and it was triaged as Critical by the platform.
Step-by-Step Breakdown:
Step 1: Navigating to Account Settings
I started by logging into my Target.com account and navigating to the Account Settings page. After adding a Visa card, a company creation screen appeared with two options: Public and Private.
Step 2: Capturing the Request
I selected the Private option, but the page appeared to be loading indefinitely. This indicated that the server was processing a request, even though the UI wasn’t updating.
Step 3: Analyzing the Response
Using Burp Suite, I intercepted the request and sent it to the Repeater. The response contained my company details, including a 32-character-long user ID, formatted like this:2ThB3jbnuh8ru5nNjnivYfjnwbfjin6HqR
Since this user ID was long and seemingly random, it didn’t seem easily guessable at first.
Step 4: Testing CSRF Validation
I modified the CSRF token in the request to a dummy value:
CSRF Token: dummy tokenSurprisingly, the server still accepted the request and returned my company details, indicating a lack of proper CSRF validation. However, this issue alone wasn’t impactful enough to report.
Step 5: Exploring Numeric User IDs
At this point, I recalled that during account creation, I had seen a numeric user ID (18356). Out of curiosity, I replaced the 32-character user ID in the intercepted request with 18356 and resent it.
🚨 It worked! I was able to view my account details, proving that the system accepted both numeric and alphanumeric user IDs.
Step 6: Predictable User ID Pattern
To verify whether the user ID assignment followed a pattern, I created a new account and observed that the user ID was 18357, just one number higher than my previous one.
I modified the request by changing the user ID to 18357 and successfully accessed details for another account.
At this point, I realized that if I reported it now, it might be triaged as Medium to High severity. I decided to dig deeper for more impact.
Step 7: Identifying the Full Impact
While testing further, I discovered that by directly hitting the /UserId endpoint without specifying an ID, the response returned all user information, making this vulnerability even more severe.
Conclusion & Impact
This IDOR vulnerability in Target.com account management system allowed me to access sensitive user information simply by changing user IDs in API requests. The predictable pattern of numeric user IDs further increased the risk, making mass exploitation possible. Combined with the lack of CSRF validation, an attacker could automate the process and extract massive amounts of data.
After reporting my findings, the issue was triaged as Critical by the platform.
🚀 Key Takeaways:
✅ Always check for IDOR vulnerabilities by modifying object identifiers in requests.
✅ CSRF validation plays a crucial role in preventing unauthorized actions.
✅ Predictable user ID patterns can turn a minor issue into a major security risk.
This was one of those satisfying moments when a simple test led to a critical bug! 🕵️♂️💻
🔒 Stay safe, keep hacking, and happy bug hunting!
