I've written about IDOR's in previous posts however this time I'm going to break down what an IDOR is and where it can be typically found. Similar to the ChargePlace Scotland IDOR, I found the issue by simply having a registered account on the platform. As per a request from the website owner, I have removed their information to ensure privacy, however had this issue been exploited over 100,000 users PII could have been disclosed.
What is a IDOR ?
An IDOR (Insecure Direct Object Reference) is a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. They typically occur when mistakes have been made around access control implementation. IDOR's can sometimes be complex and require lots of parameters to be changed or removed in order to achieve either horizontal or vertical privilege escalation within a web application, or is some cases simply changing a numerical value gets you access to another users profile information.
Finding the IDOR
Sometimes a simple bug can lead you to a bigger issue, as was the case in this instance. The website offers a discount for those that use their online portal rather than opting for a traditional paper based bill. Using the website in the normal manner I went to make a monthly payment, providing my card details and then awaited a confirmation of the transaction. Instead, the website immediately logged me out and sent me back to the main login page - I was none the wiser as to whether the transaction had been successful or not.
At this point I decided to proxy my traffic via BurpSuite to examine the HTTP requests and responses as I browsed the site. I authenticated to the web application and my first port of call was to navigate to the section where I could download my bill. Viewing the request in Burp, the 'billID' parameter and its associated value immediately jumped out as being vulnerable to tampering:
POST /youraccount/php/billdetails.php HTTP/2
Host: www.redactedcompanywebsite.com
-- Snipped --
billID=10985289¤t=true&hasBillDate=true
Increasing this parameter integer value by one, then clicking on the 'Download Bill' button allowed me to retrieve and download a pdf relating to another user. Digging further into the code of the application, I soon found that the numerical value allocated to customers is added to a hidden form field within the HTML of the page. Any user could simply use the 'Inspect element' within a browsers developer console tools, modify the billID paramter value and then use the "Download Bill" button to retrieve another users billing information.
<input type="hidden" name="billID" value="10985289">Disclosure Timeline
- IDOR found early September 2024
- IDOR reported to the website owner - 20th Sept 2024
- Website owner requested a technical report - 21 Sept 2024
- Technical Report compiled and sent to website owner - 21 Sept 2024
- Website owner accepted finding from technical report and applied fix - 24th Sept 2024
- Sanitised blog post released - 1st November 2024
Mitigations
Implement access control checks for each object that a user has access to Additionally, traditional incrementing numerical values should be replaced with more complex identifiers, such as UUID V4. Avoid exposing identifiers in URLs and POST bodies if possible. Instead, determine the currently authenticated user from session information.
Final Thoughts
From experience and throughout my security testing career, I've found quite a few IDOR's, many of them through utilising a "Download" feature. In my opinion it seems that developers often try to 'shoe horn' extra functionality into a content management system. Its worth noting that CMS's such as WordPress, Joomla, Drupal eare typically well maintained with secure code bases straight out of the box, only when you start adding in extra plugins and modules do you start to widen the attack surface and without due diligence and security testing, bugs such as these often go unchecked.
