Introduction
This blog will cover some vulnerabilities that researchers commonly encounter while doing assessment; this blog will be all about the authorization flaws that exist in modern web applications and the latest attack vectors that are in trend.
Insecure Direct Object Reference (IDOR).
IDOR is an acronym for Insecure Direct Object Reference.
What does IDOR exactly mean?
To make it easier for you to connect the dots and comprehend the meaning of IDOR, the essential terms are highlighted in bold.
Almost every application has to deal with resources. An e-commerce website, for example, will alter products, users, carts, and so on. Each resource instance will be referred to as an object, and an ID. Will identify it, for example, User A will have ID=1 and user B, ID=2. The IDOR problem is caused by a weakness in how the application references these objects. To put it another way, any vulnerability or lack of validation can allow a malevolent person to gain direct access to illegal resources.
IDOR in Numeric Values
When an application uses easy-to-guess IDs to refer to objects, it is the most common case of IDOR. They could, for example, be incremental integers or contain predictable words such as the user’s email address or a folder name. They can be badly encoded at times. For example, a base64 encoded incremental Integer or a hash reference to a profile image name. Assume that you have an application that allows you to access your data using the following endpoint GET /api/user/1337 Here if we manipulate 1337 to 1338, the profile data of 1338 will be displayed.
Privileges Escalation
Privileges are a technique that allows users to access the resource to which they are restricted/forbidden. Horizontal privilege escalation and vertical privilege escalation are the two types of privilege escalation.
Horizontal privilege escalation
Malicious actors who use horizontal privilege escalation keep their general power level and get access to data or functionality of other accounts or processes that should not be accessible to them. For example, this could entail exploiting a hacked office PC to obtain access to the data of other employees. Using session hijacking to defeat authentication and get access to another user’s account on a social site, e-commerce platform, or e-banking site is an example of horizontal escalation in web applications.
Vertical Privileges Escalation
Vertical privilege escalation (also known as privilege elevation) is more harmful since it allows the attacker to acquire access to a more privileged account – usually the administrator or system user on Microsoft Windows or root on Unix and Linux systems. The attacker can use this level of access to wreak havoc on your computer systems and apps, including stealing access passwords and sensitive data, downloading and executing ransomware, erasing data, and executing arbitrary code. Advanced attackers will disguise their tracks by removing access logs and other traces of their activities, leaving the victim utterly ignorant of the attack. Cybercriminals can steal information and install backdoors or other malware in enterprise systems in this fashion.
Example: If the admin restricts the users to view billing, and tax information in the application, here, the privileges escalation method can be of use to the attackers to view that information.
Mass Assignment
APIs hold information that should only be created, edited, updated, or deleted by specific parties. Consider a utility provider’s outstanding customer debt – a payment system should be able to update this amount depending on the customer’s payments, but the customer should not be able to directly modify this value. Because the utility company would not want their customers to decide how much they owe the firm, a mass assignment might make this number editable or deletable by the customer, which could lead to undesired API behavior. This problem can be found at the API endpoint level. These flaws can have a wide range of consequences, from trivial typos that allow a user to create a thread in a non-existent forum to account takeover or privilege escalation. For example, as an unprivileged user, you can use the profile updating page to raise your privileges to the administrator level. A user can inspect the difference between the JSON files sent as part of updating a user profile by utilizing a traffic content monitor to evaluate the JSON delivered and received from the API.
The JSON supplied to the API when a user’s profile is updated includes their name, e-mail, and chosen language for an ordinary and unprivileged user. Reference : https://galnagli.com/Mass_Assignment/
Directory Traversal
The Linux file system is made up of directories and files. We can use “dot dot slash” or “../” as an acceptable file path to go from one directory to another. The term for this is Directory Traversal.
When a web application’s user has access to files or directories stored outside of the web root folder (/var/www/html), the application is vulnerable to Directory Traversal Attack. An attacker can rewrite security-critical configuration files, read sensitive data from the server, and potentially completely compromise the application in this case.
To further comprehend this, consider the following scenario.
On Linux file systems, / var / www / html is the default web server root folder. We are hosting our website in this location. Another important location is /etc/passwd. It is used to keep track of all registered users who have access to the system. Now /var/www/html /../../../ etc / passwd is a valid file path to help you switch from the default web root folder to / etc / passwd. Therefore, a malicious user (called a hacker) can access sensitive information stored on the server by simply traversing a few directories. But the real question is how can hackers exploit this vulnerability?
Exploiting Directory Traversal Behind every successful attack is a feature that can be exploited, with weak or no defense against the attack. Certain web applications allow users to read or write directories on the server. For example, consider the following URL:
https://test.com/imageload?file=test.jpeg In this URL we are requesting a static image(test.jpeg) from the server where test.com website is hosted, by using a user-controllable parameter “file”.
The still image you are requesting is stored in the location / var / www / images, and the path to the image is /var/www/images/test.jpeg. However, if your site is vulnerable to Directory Traversal Attacks, the input is not sanitized. You can go up the hierarchy simply by adding ../ to the filename parameter.
HTTP Request with crafted input to access /etc/passwd
https://test.com/imageload?file=../../../etc/passwd
The response will show you the passwd file saved in the server root:x:0:0:root:/root:/bin/ash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/mail:/sbin/nologin news:x:9:13:news:/usr/lib/news:/sbin/nologin uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
Client Side Authorization Bypass
On the server side, the authentication and authorization status should constantly be checked and kept up to date. Developers of web applications occasionally control permission states on the client-side, where illegal access can be obtained with ease by malicious users. Maintaining state in HTTP cookies, URL routes or parameters, JSON web tokens (JWT), request referrer headers, or request origin headers are all examples of the client-side authorization state management variety.
Let’s use one from the bookstore.com application as an illustration. The application contains one administrator privilege account that the superadmin uses in addition to Alice, Bob, and Carol. Every user’s photo may be removed by the superadmin. However, the application stores the user privilege as role=superadmin on the client session cookie. Using an intercepting proxy like OWASP zap or the burp suite, it is simple to tamper with cookies that are protected with HttpOnly cookie.
It is usual for developers to underestimate the risk when creating native desktop apps, even though many contemporary software engineers are well-versed in this kind of vulnerability. The prevailing consensus is that “desktop application traffic is more difficult to intercept than web application traffic.” But this is untrue; with an intercepting proxy like mitmproxy, it is simple to intercept and interfere with even the client-server communication of desktop apps.
Conclusion
Authorization Flaws mostly occur on server-side. To keep the application safe from the attacker.These are the common vulnerability that open the door for the attacker to breach or violate the application security.
