From Auth Bypass to IDOR: Chaining Vulnerabilities to Access Other Users’ Data (PART 2)

In the previous write-up, I discussed how the "forgot password" feature could be exploited to bypass authentication, allowing users who had not been verified by an administrator to gain full access to the application.

Here you can read the PART 1

Critical Auth Bypass: How Forgot Password Feature Allowed Unverified Users to Access the Entire… In many modern applications, admin account verification is a crucial security layer to ensure only authorized users can…

However, that access turned out to be merely a starting point. After successfully entering the system without proper authorization, I discovered that the access controls within the application still harbored other, more serious vulnerabilities.

During further exploration, I discovered an Insecure Direct Object Reference (IDOR) vulnerability in the Member feature, which allowed an attacker to access other users' data simply by manipulating an identifier parameter. This combination of authentication bypass and IDOR created a dangerous attack chain, enabling an attacker not only to gain system access but also to expose and access other users' data without authorization.

After bypassing the authentication, I became interested in the Member menu.

This menu lists all members of the organization, and when I click on the details for a specific member, a popup appears displaying that member's data.

The data displayed in the popup consisted only of the name, nickname, gender, general address, and primary and secondary occupations; the endpoint was https://example.com/administrator/members/94/view_detail_member. At this point, my instincts suggested vulnerability to an IDOR attack, given that the IDs were sequential numbers. I attempted to change the ID to that of my second account — modifying the URL in the address bar to https://example.com/administrator/members/82/view_detail_member and the response indeed displayed my second account's data. However, this was merely public information, how could I access the complete, private data of other users?

So, I explored other endpoints and found one: https://example.com/administrator/members/82/edit. However, the response was a "403 Forbidden." I wondered, "What if I change 'edit' to 'view'?" I gave it a try, and voilà the response was a JSON object containing user details that were supposed to be private rather than public.

I didn't need Burp Suite to test this vulnerability, as the response was visible simply by opening the URL in the address bar. At this stage, an attacker could use a simple script to automate the extraction of all member credentials.

The Insecure Direct Object Reference (IDOR) vulnerability in this Member feature demonstrates that security concerns extend beyond the authentication stage. Although an authentication bypass flaw had previously been identified, weaknesses in internal authorization controls exacerbate the potential impact. By simply manipulating a parameter such as user_id, an attacker can access other users' data, bypassing the restrictions the system should have enforced.

When combined, these two vulnerabilities create a serious attack chain, ranging from unverified access to the ability to access data across different users. This underscores the importance of implementing comprehensive security controls, covering both authentication and authorization, as a single minor flaw can open the door to more significant exploitation.

However, the exploration did not stop there. After gaining access to other users' data via IDOR, I discovered that the application was also vulnerable to Stored Cross-Site Scripting (Stored XSS) in the user profile editing feature.

This vulnerability allows an attacker to inject a malicious payload that is stored within the system and executed whenever the data is displayed whether to other users or to an administrator. Within the same attack chain, this Stored XSS can be leveraged to escalate the attack's impact, such as by stealing sessions, performing actions on behalf of other users, or even taking over accounts with higher privileges.

See you in Part 3 :)