IDOR – Santa’s Little IDOR: THM Walkthrough

IDOR Room: The elves of Wareville are on high alert since McSkidy went missing. Recently, the support team has been receiving many calls from parents who can’t activate vouchers on the TryPresentMe website. They also mentioned they are receiving many targeted phishing emails containing information that is not public. The support team is wary and has enlisted the help of the TBFC staff. When looking into this peculiar case, they discovered a suspiciously named account named Sir Carrotbane, which has many vouchers assigned to it. For now, they have deleted the account and retrieved the vouchers. But something is going on. Can you help the TBFC staff investigate the TryPresentMe website and fix the vulnerabilities?

Learning Objectives

• Understand the concept of authentication and authorization
• Learn how to spot potential opportunities for Insecure Direct Object References (IDORs)
• Exploit IDOR to perform horizontal privilege escalation
• Learn how to turn IDOR into SDOR (Secure Direct Object Reference)

Start your target VM by clicking the Start Machine button below. The machine will need about 2 minutes to fully boot. Additionally, start your AttackBox by clicking the Start AttackBoxbutton below. The AttackBox will start in split view. In case you can not see it, click the Show Split view button at the top of the page. Inside your AttackBox, open a web browser and navigate to the TryPresentMe application at http://MACHINE_IP.

My target machine and the AttackBox have started and I am ready to learn about IDOR.

No Answer Needed

Task 2 IDOR on the Shelf

It’s Dangerously Obvious, Really

Have you ever seen a link that looks like this: https://awesome.website.thm/TrackPackage?packageID=1001?

When you saw a link like this, have you ever wondered what would happen if you simply changed the packageID to 11 or 12? In its simplest form, this can be a potential case for IDOR. 

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability. Web applications often use references to determine what data to return when you make a request. However, if the web server doesn’t perform checks to ensure you are allowed to view that data before sending it, it can lead to serious sensitive information disclosure. A good question to ask then is:

Why does this happen so often?

We need to understand references and web development a bit more to answer this. Let’s take a look at what a table storing these package numbers from our link example could look like:

packageID	person	address	status
1001	Alice Smith	123 Main St, Springfield	Delivered
1002	Bob Johnson	42 Elm Ave, Shelbyville	In Transit
1003	Carol White	9 Oak Rd, Capital City	Out for Delivery
1004	Daniel Brown	77 Pine St, Ogdenville	Pending
1005	Eve Martinez	5 Maple Ln, North Haverbrook	Returned

If the user wants to know the status of their package and makes a web request, the simplest method is to allow the user to supply their packageID. We recover data from the database using the simplest SQL query of:

SELECT person, address, status FROM Packages WHERE packageID = value;

However, since packageID is a sequential number, it becomes pretty obvious to guess the packageIDs of other customers, and since the web application isn’t verifying that the person making the request is the same person as the one who owns the package, an IDOR vulnerability appears, allowing attackers to recover the details for packages belonging to other users. Even worse is when a feature like this doesn’t require a user to authenticate, then there would be no way to even tell who is making the request! To dive a bit deeper, we need to understand authentication, authorization, and privilege escalation.

A note from one of the co-authors of this task: I am not a fan of the vulnerability name IDOR. I prefer the name authorization Bypass. If you want to understand my reasoning, expand here, but you don’t have to be bored with the details!

It Doesn’t Obviously Relate

The full term, Insecure Direct Object Reference, sounds fancy, but it doesn’t really describe what’s going wrong. The “Direct Object Reference” part just means that a system uses an ID (like /user/1) to point to something. That’s not the problem. The real issue is that the system doesn’t check whether the person making the request is allowed to access it.

A lot of people try to “fix” IDORs by hiding or encoding IDs. For example, changing /user/1 to /user/ea21f09b2. That might make it look harder to guess, but if the server still isn’t checking permissions, it’s just as insecure. The vulnerability isn’t about how the object is referenced, it’s about missing authorization checks.

That’s why I prefer to call it an Authorization Bypass instead. It explains exactly what’s happening: someone is bypassing the rules that decide who can see or change something. Whether the ID is a number, a hash, or a random string, the risk stays the same if the server doesn’t verify access. You can read more here if you want.

Identity Defines Our Reach

To understand the root cause of IDOR, it is important to understand the basic principles of authentication and authorization:

• Authentication: The process by which you verify who you are. For example, supplying your username and password.
• Authorization: The process by which the web application verifies your permissions. For example, are you allowed to visit the admin page of a web application, or are you allowed to make a payment using a specific account?

You may think that authentication only happens once when you supply your username and password, but that is actually not the case! After providing your credentials, you receive a cookie or a token, called session information. Every subsequent request you make to the application includes this session information, which is verified by the application. This initial verification process is still authentication and happens for each request. This is why websites will often redirect you back to the login page. It means your session information has expired, and thus, you need to reauthenticate with your credentials to receive new session information.

Authorization cannot happen before authentication. If the application doesn’t know who you are, it cannot verify what permissions your user has. This is very important to remember. If your IDOR doesn’t require you to authenticate (login or provide session information), such as in our package tracking example, we will have to fix authentication first before we can fix the authorization issue of making sure that users can only get information about packages they own.

The last bit of theory to cover is privilege escalation types:

• Vertical privilege escalation: This refers to privilege escalation where you gain access to more features. For example, you may be a normal user on the application, but can perform actions that should be restricted for an administrator.
• Horizontal privilege escalation: This refers to privilege escalation where you use a feature you are authorized to use, but gain access to data that you are not allowed to access. For example, you should only be able to see your accounts, not someone else’s accounts.

IDOR is usually a form of horizontal privilege escalation. You are allowed to make use of the track package functionality. But you should be restricted to only performing that tracking action for packages you own. Now that we understand the theory, let’s look at how to exploit IDOR practically!

Task 2 Questions

Question: What does IDOR stand for?

Insecure Direct Object Reference

Question: What type of privilege escalation are most IDOR cases?

Horizontal

Here horizontal because we are escalating privilege with same user level like in same line

Question: Exploiting the IDOR found in the view_accounts parameter, what is the user_id of the parent that has 10 children?

15

Bonus Task: If you want to dive even deeper, use either the base64 or md5 child endpoint and try to find the id_number of the child born on 2019-04-17? To make the iteration faster, consider using something like Burp’s Intruder. If you want to check your answer, click the hint on the question.

19

Bonus Task: Want to go even further? Using the /parents/vouchers/claim endpoint, find the voucher that is valid on 20 November 2025. Insider information tells you that the voucher was generated exactly on the minute somewhere between 20:00 – 24:00 UTC that day. What is the voucher code? If you want to check your answer, click the hint on the question.

 22643e00-c655-11f0-ac99-026ccdf7d769

If you enjoyed today’s room, check out our complete IDOR room!

Thank you for reading this post, don't forget to subscribe!