IDOR & HTTP Security Headers

Insecure direct object reference (IDOR) is a type of security vulnerability that occurs
when an application allows a user to manipulate a direct object reference (such as an
ID number or file name) to access unauthorized resources.

An attacker can exploit this vulnerability by manipulating the object reference to

access sensitive data or functionality that they should not have access to.

For example, suppose a web application allows users to view their account details by
providing their account ID in the URL. The URL might look something like this:

https://banksite.com/account?id=1234

In this case, the account ID "1234" is used as a direct object reference to retrieve the
user's account details from the database.

If an attacker can guess or manipulate the account ID parameter in the URL, they may
be able to access other users' account details, even if they don't have permission to
do so.
For instance, an attacker may try to access the account details of another user by
changing the account ID parameter in the URL to a different value:

https://banksite.com/account?id=1235

If the application does not properly validate the user's access rights to the requested
account, the attacker could access the sensitive information of another user.

Common Types of IDOR

Identifiers are becoming more frequently seen in headers or APIs rather than directly
in a user's address bar. However, because most websites are dynamic, identities and
parameters are still widely utilized in some capacity.

Among the possible identifiers are:

• Database keys
• Query parameters
• User or session IDs
• Filenames

How Do IDOR Vulnerabilities Get Executed?

Attackers frequently employ the Burp Suite Tool to carry out these kinds of attacks.

Follow the steps below:

Step 1: Obtain the Request

An attacker will first choose the website that would be the target of his IDOR assault.
The website is then included in the scope and spidered to collect all of the URLs with
the desired criteria.
Step 2: Request Parameter Filtering

Following the initial step, we will filter our collected requests using the parameter filters.
The only options available to an attacker for attack execution are that parameter or
injection points.

Step 3: Send Request to Repeater

At this stage, if an attacker finds any injection places where they can run IDOR, they will
request the repeater. The vulnerable URL may be something
like www.abc.com/myaccount/uid=23. In this case, the "UID" appears to be weak.

Step 4: Parameter Tampering

Now that the attacker has access to the weak injection point, they will attempt to carry
out the IDOR attack using social engineering or the pattern specified in the injection
point. For instance, if an attacker changes uid from 23 to 24, another user’s account
with the ID number 24 will be opened.

Types of IDOR Attacks

Most IDOR-based attacks operate in similar ways, however, there are small
differences in how the identifier is revealed and/or exploited by hackers.

Below is a list of the four different types of IDOR attacks:

Body Manipulation:

Body manipulation is extremely similar to URL tampering, however, instead of altering

the URL, the attacker changes one or more values in the document's body.

The values of checkboxes, radio buttons, and other form elements may need to be
changed to do this. Potentially, hidden form values might also be modified.
The user ID for the account that is currently logged in may be passed on by a contact in
a hidden form field. We can make our request appear to come from a different user if we
can change that hidden value before submitting the form.

URL Tampering:

URL Tampering refers to changing the parameter value of the URL.

For example, let’s suppose there’s an example URL that may be something like
‘http://example.com/category/photos_id=1’

In this parameter, we are authorized to see the data of ID ‘1’.

But if we could change the value from 1 to 2 such as

‘http://example.com/category/photos_id=2’, and if we could see the data of this
particular URL, in such case it can be considered as URL Tampering.

Cookie ID Manipulation:

Cookies are used to store and exchange data between the client and server. It helps in
identifying specific users and provides a good browsing experience to the user.

In such cases, if there’s an IDOR vulnerability then there might be a possibility to

manipulate a cookie ID.

For example, there’s a cookie id in a web application that may be something like this
_gid=123456 which is for user A, and another cookie id is _gid=789012 which is for
user B.

So, if user A can change the value of _gid and replace the ID of user B and can see any
information which belongs to user B then there’s an IDOR.
 Directory Traversal:

Directory Traversal is also known as a Path Traversal attack where an attacker can
access or manipulates the files and folders which should not be allowed to access
publicly. If there is a Directory Traversal vulnerability exists in a web application then
the attacker can easily able to see some sensitive files or folders such as images, themes,
scripts, and so on.

For Example, the user is able to display unauthorized files.

https://www.example.com/display_file.php?file.txt

If there is an IDOR vulnerability associated with the display_file.php script, a

malicious hacker could gain access to sensitive file system resources such as
the /etc/passwd file:

https://www.example.com/display_file.php?../../../etc/passwd

Impact of IDOR Vulnerabilities

The impact of an Insecure Direct Object Reference (IDOR) vulnerability can be

significant and can vary depending on the specific application and the data or
functionality that is exposed. Here are some examples of potential impacts of IDOR
vulnerabilities:

1. Unauthorized Data Access:

An attacker who exploits an IDOR vulnerability may be able to access sensitive

data that they should not have access to. This could include personal identifying
information (PII), financial information, confidential business information, or
intellectual property.
 2. Privilege Escalation:

In some cases, an attacker who exploits an IDOR vulnerability may be able to

escalate their privileges and gain administrative access or other elevated
permissions. This could give them the ability to execute further attacks or cause
additional damage.

3. Data Manipulation or Deletion:

An attacker who exploits an IDOR vulnerability may be able to manipulate or delete

data that they should not have access to. This could include modifying orders,
deleting records, or altering financial transactions.

4. Reputation Damage:

An IDOR vulnerability that results in a data breach or other security incident can
damage an organization's reputation and erode customer trust. This can result in
lost business, legal liability, and other negative consequences.

Remediation of IDOR Vulnerability

 Developers should avoid displaying private object references such as keys or file
names.
 Validation of Parameters should be properly implemented.
 Verification of all the Referenced objects should be done.
 Tokens should be generated in such a way that they should only be mapped to
the user and should not be public.
 Use random identifiers so that it will be a little bit hard to guess for attackers.
 Validation of user input should be properly implemented.
HTTP Security Headers
HTTP security headers are response headers that can be included in HTTP(S)
responses from a web server to provide additional security protections to web
browsers and other user agents.

These headers help protect against various types of attacks, including cross-site
scripting (XSS), clickjacking, and MIME-type sniffing.

Here are some commonly used HTTP security headers:

 Content Security Policy (CSP):

CSP headers allow websites to define a policy that specifies which sources of
content are allowed to be loaded and executed on the page. This helps prevent
XSS attacks by blocking the execution of scripts that are not explicitly allowed by
the policy.

 X-XSS-Protection:

The X-XSS-Protection header is an HTTP response header that helps protect

websites against script injection attacks, which occur when an attacker injects
malicious JavaScript code into an HTTP request to steal sensitive information like
session cookies.

When a browser receives an HTTP response containing the X-XSS-Protection

header, it checks the content for any reflected cross-site scripting (XSS) attacks. If
an attack is detected, the browser can be configured to block or sanitize the
content to prevent the attack from succeeding.
XSS attacks are a prevalent and effective type of web attack, and the X-XSS-
Protection header is a useful defence mechanism for web applications.

 X-Content-Type-Options:

The X-Content-Type-Options header is an HTTP response header that prevents

web browsers from interpreting a response with an incorrect MIME type. In other
words, it tells the browser to use the declared content type instead of "sniffing" the
content and guessing the type.

Without this protection, attackers can exploit MIME-sniffing vulnerabilities to inject

malicious code into a response that the browser then executes as if it were a
legitimate resource, such as an image. For example, an attacker may modify the
response for an innocent image file to include a malicious script. Without X-
Content-Type-Options, the browser may incorrectly interpret the file as a script and
execute it, leading to a potential attack.

By using the X-Content-Type-Options header, web developers can ensure that the
browser will always interpret responses with the correct MIME type, preventing
attacks that exploit MIME-sniffing vulnerabilities.
 X-Frame-Options:

This header prevents a page from being displayed in an iframe, which can help
prevent clickjacking attacks.

 Strict-Transport-Security (HSTS):

HTTP Strict Transport Security (HSTS) is an HTTP response header that can be
used to protect websites against man-in-the-middle attacks and cookie hijacking.
Suppose you have a website called www.example.com, and you have recently
migrated it from HTTP to HTTPS by purchasing an SSL certificate. However, some
users may still access your site using HTTP. To address this, you can redirect
HTTP users to HTTPS. However, during the redirection process, there is a risk of a
man-in-the-middle attack, where an attacker intercepts the traffic and poses as the
website to steal sensitive information.

To prevent this, the HSTS header can be used. When the browser sees the HSTS
header in the response, it is instructed to always use HTTPS to access the site,
even if the user types in the HTTP URL or if an attacker tries to redirect the user to
an HTTP URL. This prevents the risk of man-in-the-middle attacks and ensures that
sensitive information is always transmitted securely over HTTPS.

 Referrer-Policy:

This header controls how much information about the referring page is sent to the
destination site, which can help protect user privacy.
REFERENCE

https://spanning.com/blog/insecure-direct-object-reference-web-based-
application-security-part-6/
https://portswigger.net/web-security/access-control/idor
https://crashtest-security.com/insecure-direct-object-reference-idor/
https://www.invicti.com/learn/insecure-direct-object-references-idor/
https://www.acunetix.com/blog/web-security-zone/what-are-insecure-direct-
object-references/
https://www.scaler.com/topics/cyber-security/idor/
https://www.geeksforgeeks.org/insecure-direct-object-reference-idor-
vulnerability/
https://www.loginradius.com/blog/engineering/http-security-headers/
https://www.wpoven.com/blog/http-security-headers/