Hunting for Corporate Accounts: Exploiting IDOR and Parameter Pollution in Web Applications

IDOR Exploitation: Initial Failures and Breakthrough

While testing the “My Profile” section, I immediately noticed that the application used a unique id parameter in the URL to retrieve user profiles. This raised a red flag for potential IDOR vulnerabilities. I began by simply changing the id value in the URL to see if I could view other users' profiles.

Initially, I faced failure after failure. No matter what id value I entered, the application consistently responded with the same error message, informing me that “an error had occurred.” I tried switching the id to character values, injecting additional parameters, and even mixing numeric and special characters, but nothing seemed to work.

Undeterred, I continued experimenting. Eventually, I attempted something more unconventional: I tried setting the id parameter twice, using id=200&id=201. The first id value (200) corresponded to my own account, while the second id (201) was an identifier for another user’s profile. This time, something surprising happened. The page actually displayed the name and details of another user, while still confirming the session as mine.

It had worked.

By somehow bypassing the validation check, the server used the first id value (200) to confirm my access, but displayed information tied to the second value (201). This trick effectively bypassed the IDOR check, allowing me to view details from another user's account.

Parameter Pollution: Automating Enumeration

Once I had successfully exploited IDOR, I shifted my focus to automating the attack. Parameter pollution made this process incredibly effective. By systematically sending requests with varied id values, I was able to determine which values corresponded to active user profiles.

Using a basic automation script along with curl and grep, I filtered through the responses and compiled a list of 600 active user names on the application. The lack of access control validation on the id parameter allowed me to scale the attack, rapidly mapping the entire user base. This was a clear sign of a severe security oversight.

From Names to Emails: Corporate Account Enumeration

With a full list of user names at my disposal, the next logical step was to identify the email addresses tied to these accounts. In targeted attacks, having access to corporate email addresses can be crucial, so I employed some basic corporate email formatting rules:

Using these patterns, I generated a list of possible emails for each user. The goal was simple: find 600 corporate emails that had active accounts on the application. Since these emails were not displayed on user profiles, uncovering them could provide significant leverage for future attacks, such as credential stuffing or phishing.

Exploit in the Edit Profile Section: Account Enumeration Vulnerability

The next vulnerability surfaced in the “Edit Profile” section of the application. Here, users were allowed to change their registered email addresses. However, the system’s response revealed a critical weakness. When entering a new email address, the server responded with one of two messages:

This presented a golden opportunity for account enumeration. By automating the process and testing my generated email list, I could easily identify which corporate emails were registered on the application. With each request, the server’s responses allowed me to determine which email addresses were valid.

Automation Challenge: Dealing with “Verification Pending”

As I began automating this attack, I encountered an obstacle: every time I sent an email that wasn’t registered, the application entered a “Verification Pending” state. This meant that no further email change requests could be processed unless I either verified the pending email or manually canceled the request.

This posed a significant challenge for automation, as manually canceling each email change request would have drastically slowed down the attack.

However, after analyzing the email change process through a web proxy, I discovered a workaround. I noticed that the server accepted a POST request to cancel the email change. By sending this request each time I received a “Verification Pending” response, I could automate the cancellation and continue the attack seamlessly.

Combining Vulnerabilities: Mapping Names to Emails

After overcoming the challenge of automating the email enumeration, I was able to combine the data from the IDOR and account enumeration vulnerabilities. This allowed me to map the 600 user names to their corresponding corporate email addresses. Having these valid email addresses provided a complete set of targets for potential phishing campaigns, password resets, or brute-force login attempts.

Impact: A Blueprint for Targeted Attacks

This blog demonstrates how combining vulnerabilities — IDOR, parameter pollution, and account enumeration — can lead to severe consequences. With just a few steps, I was able to extract the names and corporate email addresses of all users, leaving the door open for targeted attacks.

Thank you for your attention. I look forward to sharing more insights in future articles!

Connect with me on LinkedIn