Hi everyone, Jivan here!
I’m back with another Android vulnerability report.
In this write-up, I’ll walk you through how I discovered an IDOR (Insecure Direct Object Reference) vulnerability in an Android application. This issue allowed me to access Customer Booking / Reservation Information without proper authorization.
Let’s dive into the details of how I identified and exploited this vulnerability responsibly
Due to security reasons, I can’t disclose the Android app or company name, so I’ll refer to it as [Redacted App]. This app provides hotel booking services to users, and it’s where I discovered the vulnerability.
Once I saw that the target was in scope, I immediately downloaded the [Redacted App] onto my Android emulator. After downloading, I set up Burp Suite with my emulator to intercept and analyze the app’s traffic.
Before jumping into bypass attempts, I always prefer to manually explore the app to understand its core functionalities. When I launched the app, it opened but immediately displayed an error message on the screen.
After seeing the “Security risks” error popup, I suspected it was caused by SSL pinning. To confirm and bypass it, I decided to use Frida. First, I enabled the proxy on the emulator to intercept the app’s traffic, then started the Frida server inside the emulator. I ran a Frida JavaScript bypass script using the [Redacted App]’s package name.
However, even after doing this, the same error popup appeared. I repeated the SSL pinning bypass steps a few more times, but still had no luck in getting past the security check.
After testing for SSL pinning bypass, I confirmed that the application was also performing a root detection check. This meant I needed to bypass both SSL pinning and root detection to interact with the app normally. Instead of continuing with Frida, I switched to Objection, a tool that supports bypassing both mechanisms simultaneously. I ran Objection with the [Redacted App] package name, and successfully bypassed the app’s security checks, allowing full access to its features.
Important Note on Objection Tool Bypass Behavior
I want to clarify an important point regarding the use of the Objection tool for bypassing SSL pinning and root detection in the [Redacted App]. When I attempted the bypass, I executed the following Objection commands:
android sslpinning disable
android root disable
After running these commands, the [Redacted App] launched, but it still displayed a “Security Risks” error popup. This indicates that the bypass was not immediately successful, and Objection failed to disable the security checks at that point. You can refer to the attached screenshot, where the Objection tool is running without any error, but the app still shows the warning popup.
Now, here’s the key part:
When this kind of error popup appears, do not exit Objection. Instead, interact with the popup (the options might be OK, Cancel, Exit, etc.). In my case, the option shown was “Confirm”, so I clicked on it. The app then closed automatically.
At this point, I did not stop the Objection tool—I simply clicked on the app again to relaunch it. After doing this, the Objection tool was finally able to successfully bypass both root detection and SSL pinning, as shown in the second screenshot.
This is a useful trick if you face a similar situation: even if the first launch fails with a security popup, retrying the app launch without exiting Objection may result in a successful bypass.
Exploring Functionality After Bypass
After successfully bypassing root detection and SSL pinning for the [Redacted App], I proceeded to create a test account within the app. With full access enabled, I began exploring various functionalities and testing multiple API endpoints for potential vulnerabilities.
During this process, I discovered an interesting endpoint related to hotel room availability. This endpoint allows a user to check whether a specific room is available or already reserved by supplying a date as a parameter.
From the application’s user interface, users are limited to checking booking availability for up to 30 days from the current date. However, this limitation is enforced on the client side, which made me curious about how the backend handles date-based queries.
After identifying the room availability feature, I captured the corresponding GET request in Burp Suite. When the room is available, the server responds with a JSON object containing the status—such as "open": true indicating that the room is available.
However, if the room is already reserved, the response includes booking details, such as the reservation information of the user who booked it.
After intercepting the request, I modified the date parameter with a custom value and re-sent the request. To my surprise, the server responded with user reservation information, including details such as reservation date, first name, and surname—which confirmed the presence of an Insecure Direct Object Reference (IDOR) vulnerability.
To demonstrate the broader impact, I sent this request to Burp Suite’s Intruder tab, selected the date parameter, and generated 30 payloads using different date values. As a result, I was able to access multiple users’ booking information, proving the severity of the issue.
After discovering the vulnerability, I submitted my findings to the company along with a detailed description, impact analysis, and recommended solution. The security team reviewed and confirmed the issue, classifying it as a High Severity vulnerability. As a result, I was rewarded with a bug bounty of $80 USD for my responsible disclosure.
🙏 Thanks for taking the time to read my write-up!
If you found it insightful or learned something new, feel free to connect with me or drop your thoughts in the comments — I’d love to hear from you.
Until next time, stay curious, stay sharp, and keep hacking responsibly. 🚀🔐
