INSECURE DIRECT OBJECT REFERENCE (IDOR)

Insecure Direct Object Reference is a type of access control vulnerability where the user is given too much trust due to input data not being validated on the server side. This leads to the user being able retrieve objects (files, data, documents) that they should not have access to. 


Where are IDORs located?

The vulnerable endpoints could be in an adress bar, the content loaded in via an AJAX request or something found in a JavaScript file. 

In the below example, I was able to view an invoice that did not belong to me by changing the invoice number in the URL. This could also apply to user_id to access other users accounts.





Finding IDORS in Encoded IDs and Hashed ID's

When passing data from page to page via post data, query strings or cookies developers will often take the data and encode it to ensure the receiving web server will be able to understand the contents. Encoding changes binary data in to an ASCII string, most commonly using base 64 encoding. Websites such as https://www.base64decode.org/ can be used to decode the string. With the decoded string, it is possible to edit it, encode it and then pass it back to the web server. See the below image for an example.



Hashed ID's cannot be decoded, however there are databases, such as https://crackstation.net/, where hashes can be searched against already known values. This can be useful if searching for common words, such as "user".

Unpredictable ID's 
If the ID cannot be detected using the above methods, a possible avenue for IDOR detection is to create two accounts and swap the ID numbers between them. If I am able to view the other users regardless of log in state then this an IDOR vulnerability.


Practical IDOR Example

In this example I am able to create an account and log in to view information about my account. When examining the Network tab of the Developer Tools,  I can see that the page is returning to me my user id. 

I can edit this field to attempt to view other users account information. In this example I am viewing the user with the id of 3.


I can then view this and see the users log in information.







Comments

Post a Comment

Popular posts from this blog

BURPSUITE IN-DEPTH

Image
NOTE: This post will be a much deeper and in-depth dive in to some of the functionality of Burp Suite. If you need a quicker overview, please visit my  Burp Suite Basics  post.  Repeater The repeater function of Burp Suite allows us to take a request captured by Proxy, edit it and send the same request repetitively. This makes repeater ideal for any manual poking around at an endpoint. Basic Usage: The repeater interface can be split in the 6 main sections. Refer to the image above: List of requests that are going through Repeater. Controls for the current request, these allow us to send/cancel a hanging request and go forwards/backwards in a request history. Request/Response view. Requests are edited in the Request view and Responses will show up in the Response view. Allows us to change the layout for the Request and Response view. The inspector allows us to break requests apart and analyse and edit them in a more intuitive way than the raw editor. The IP address o...
Read more

PASSIVE AND ACTIVE RECONNAISSANCE

Image
In this post we will learn about passive and active reconnaissance. Passive reconnaissance lets us gather information about a target without any kind of direct engagement. Active reconnaissance requires us to make some kind of contact with out target. Some Passive Reconnaissance tools we will explore: whois nslookup dig DNSDumpster Shodan.io Some Active Reconnaissance tools we will explore: ping traceroute telnet nc Passive Reconnaissance In passive reconnaissance, we rely on publicly available knowledge that can be accessed without directly engaging the target. Passive recon may include: Looking up DNS records from a public DNS server Checking job ads related to the target website Reading news articles about the target company Visiting social media sites of the company or their employees Whois Whois is a request and response protocol that follows the  RFC 3192  specification. A whois server listens on port 43 for incoming requests. A domain registrar is responsible for mainta...
Read more

CROSS-SITE SCRIPTING

Image
Cross-Site Scripting (XSS) is an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by other users.  XSS Payloads In XSS the payload is the JavaScript code we wish to be executed on the targets machine. The payload is comprised of two parts, the intention and the modification. The intention is what the attacker intends the JavaScript to execute and the modification is the changes the attacker needs to do on the code to make it execute in each specific scenario.  Proof of Concept This is a simple payload in order to prove that an attacker can actually achieve XSS on a website: <script>alert('XSS');</script> Session Stealing Details of a users session, such as log in tokens are often kept in cookies on the targets machine. The below JavaScript takes the target's cookie, base64 encodes it to ensure successful transmission and then posts it to a website under the attackers control <script>fet...
Read more