Shulou(Shulou.com)05/31 Report--

This article will explain in detail the case analysis on the discovery of IDOR vulnerabilities. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

I like to engage in IDOR vulnerabilities very much, which is often called unsafe direct object reference or ultra vires. Generally speaking, it is relatively simple to find and not too difficult to use, but it has a serious harmful impact on the website business. As far as I'm concerned, most of the high-risk vulnerabilities I found before fall into the category of IDOR vulnerabilities. Today we will talk about how to discover more IDOR vulnerabilities.

Introduction of IDOR vulnerabilities

IDOR,Insecure Direct Object reference, or "unsafe direct object reference", the scenario does not validate permissions when accessing based on input objects provided by the user. In fact, IDOR vulnerabilities fall within the scope of Broken Access Control vulnerabilities, which can also be described as logic vulnerabilities or access control vulnerabilities, which are often referred to as ultra vires vulnerabilities in China. You can click this reference for details.

However, IDOR vulnerabilities are not as simple as adding, subtracting and switching digital ID numbers. as the functions of applications become more and more complex, they refer to resources in a variety of ways, which also means that simple digital IDOR vulnerabilities are becoming less and less in most network applications. IDOR is reflected in different ways in Web applications. In addition to the usual simple number ID number, let's discuss a few more noteworthy points.

Look for IDOR loopholes in unexpected places. Don't forget to code or hash the ID number.

When we are dealing with an encoded ID, it is always possible to decode the encoded ID in some way. If the Web application uses a hash or random ID encoding, we need to see if the ID is guessable. Sometimes Web applications use some insufficient entropy algorithms (algorithms that produce insufficient entropy). In fact, after careful analysis, we can predict the ID number. For example, we can register several accounts to analyze the specific generation mode of this ID number, and then summarize the generation method of other users'ID numbers.

In addition, you can also spy on some leaked random or coded ID through other API interfaces, such as some public pages of Web applications, such as user profile information pages, referer links and so on.

For example, if I find an API interface, its function is to allow users to obtain some of their own detailed private messages through an encoding session ID. The request format is as follows:

GET / api_v1/messages?conversation_id=SOME_RANDOM_ID

At first glance, the session ID (conversation_id) is very long and is a random alphanumeric sequence, but then I found that you can use the user ID number to get a list of sessions that belong to each user! As follows:

GET / api_v1/messages?user_id=ANOTHER_USERS_ID

The session ID number (conversation_id) that belongs to the user is included in this session list, and because the user ID (user_id) can be found publicly in each user's profile page, so by combining these two ID numbers, I can read any user and private message session content through the interface / api_v1/messages!

If you cannot guess, you can try to create

For example, if the object reference number (object reference IDs) is unpredictable, you can see what can be done to affect the process of creating or linking the ID number.

Provide a request ID to the Web application, even if it does not require it

If the Web application does not require an ID number in the request action, you can try to add an ID number to it and see what happens. For example, add a random ID number, user ID, session ID, or other object reference parameters to observe the response of the server. For example, the following request API is used to display the content of the private message session to which the current user belongs:

GET / api_v1/messages

If you change it to this style, will it show the conversation content of other users?

GET / api_v1/messages?user_id=ANOTHER_USERS_ID using HTTP parameter pollution method (HPP,HTTP parameter pollution)

Using HTTP parameter pollution to give it multiple different values for the same parameter can also lead to IDOR vulnerabilities. Because Web applications may not be designed to expect users to submit multiple different values for a parameter, it may sometimes cause access to the Web backend interface to bypass. Although this situation is very rare and I have never encountered it, it is theoretically possible. Such as the following request API:

GET / api_v1/messages?user_id=ANOTHER_USERS_ID

If the request for it fails, we can try to make another request as follows:

GET / api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

Or this request:

GET / api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID

Or replace it with a request to list the parameters:

GET / api_v1/messages?user_ids [] = YOUR_USER_ID&user_ids [] = ANOTHER_USERS_ID using blind IDOR method (Blind IDORs)

In some scenarios, interfaces vulnerable to IDOR vulnerabilities do not respond directly to requests for query information, but they can cause Web applications to disclose information in other aspects, such as exported files, e-mails, or text alerts.

Change the request method

If a request method is invalid, you can try other methods, such as GET, POST, PUT, DELETE, PATCH... A common technique is to exchange PUT and POST because the access control measures on the server side are not perfect.

Change the type of request file

Sometimes, switching the type of request file may cause the Web server to make a difference in authorization processing, such as adding a .json after the request URL to see how the response results.

How to improve the criticality and severity of IDOR vulnerabilities IDOR priority

Here, when looking for IDOR vulnerabilities, the first thing to consider is its impact on the key business of the target website, so read-write IDOR vulnerabilities belong to high-risk IDOR vulnerabilities.

According to the state-changing state-changing (writable) IDOR vulnerability, the operations such as password reset, password change or account recovery will have a serious impact on the critical business of the target website, while the impact of the IDOR vulnerability of changing email subscription settings is lower.

As for the state immutable non-state-changing (readable) IDOR vulnerability, we should pay attention to its handling of sensitive information, such as the handling of user private message sessions, the handling of user sensitive information, or the handling of non-public content. Consider which functions in the Web application will process this data, and then target to find similar IDOR vulnerabilities.

Storage XSS (Stored-XSS)

If you combine writable IDOR with self-XSS (XSS that requires victim interaction), it is possible to form a storage XSS (Stored-XSS) for a particular user. Where is its use of force? For example, if you find an IDOR vulnerability that can change another user's shopping cart list, in fact, the IDOR vulnerability is not very harmful, at best it will only cause some trouble to the victim, but if you use it in conjunction with self-XSS, at a certain user submission point, you can pass the XSS utilization code to the victim's browser through IDOR. It forms a storage XSS for specific victimized users and requires no interaction!

This is the end of the case analysis on the discovery of IDOR vulnerabilities. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.