Insecure Direct Object References- A Security Hole
A “strange” security hole with a long, and difficult-to-read name.
What is strange?
This security hole is “strange” in that it is in the top 4 OWASP, but there is very little documentation about it. It is not known as XSS or CSRF or SQL Injection (Although its OWASP rank is much higher than XSS or CSRF).
I myself have never heard of the press or news mentioning this error before. Is it possible that there are no well-known cases related to it, or is it because the bug has many complex variations?
The main cause of this vulnerability is the carelessness of a developer or sysadmin (If you encounter this error, you have to drag the developer to cut first, then cut the tester).
This vulnerability occurs when the program allows users to illegally access resources (data, files, folders, database) through the user's data.
How to take advantage of the vulnerability
Very casually, I discovered this error while helping a younger brother test the sales web project.
In the “Manage Orders” section, the URL of an order will look like this: http://shop.com/user/order/1230. The server will read ID 1230 from the URL, then find the order with ID 1230 in the database and dump the data into HTML.
Imitating the hacker, I “playfully” a bit, replacing 1230 with the values from 1 to 2000. The system just read and displayed all orders with IDs from 1 to 2000 (including orders of other customers). Harmful yet!
The flaw is: the program allows me to access illegal resources (other people’s orders), through data (ID) that I provide through the URL. The program should have checked to see if it had access to these data.
Hackers can use many tricks such as changing URLs, changing API parameters, and using tools to scan unsecured resources. My old hack lotte cinema is similar, replacing the URL with the username in the cookie.
There are a few rare cases; hackers can scan the git repository located on the server. Git access, he gets the username, password of the database and other important information.
Some preventive measures:
Test carefully — The cause of the error is often the carelessness of the developer. However, if the product fails, this is the tester’s fault. This is an error in the code, so the tester is responsible for letting this error happen to the user.
Data protection “jump sensitive” — For “sensitive” data such as source code, config, database key, it is necessary to limit access. The best way is to allow the internal IPs to access this data, hackers away from the computer.
Most important: Strictly check user permissions
Avoid exposing the object’s key — In the above cases, the object’s id is an int so that the hacker can guess other objects' id. To prevent this, we can encrypt id, using GUID as id. Hackers cannot detect the ID of another object.
Some additional sources for reference:
OWASP Top Ten
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad…