How to understand IDOR vulnerabilities for your protection

The Australian Signals Directorate's Australian Cyber Security Centre (ACSC), U.S. Cybersecurity and Infrastructure Security Agency (CISA), and U.S. National Security Agency (NSA) have released a joint cybersecurity advisory warning vendors, designers, and developers of web applications and organisations using web applications about insecure direct object reference (IDOR) vulnerabilities, also known as broken object level authorisation (BOLA) vulnerabilities.

An IDOR is an object on a web server, such as a user's profile, that can be accessed without controls to that access being in place. In other words, 12345 has this issue since the user could just change the number on the end of the query string. 12346 would be the next user, and the access controls wouldn't check to see if 12345 was supposed to see 12346's profile.

The advisory provides some good advice, but it's important to note that even if things are designed well, and code scanners and reviews have taken place, it's possible to end up with an issue.

One of the glaring things the advisory is missing is the fact that for a while now, a transaction-by-transaction account of the intent of each transaction is possible.

This means that looking at a transaction where someone looks at 12345's profile when they try to see 12346's profile, the transaction will be flagged/dropped/alerted on/given a deceptive response, etc., which goes far beyond the basics and requires a deeper look but is a far faster way to deal with it.

Never forget the basics, and as such, the advice in the advisory is sound, but to understand where they are coming from, let's look at the types of IDOR/BOLA they are talking about:

Horizontal IDOR vulnerabilities: This is the one most people understand. As a regular user, I can see another regular user's information. It's called Horizontal IDOR or Horizontal Privilege Escalation because the attacker and the victim are at the same user level or unauthenticated, not an administrator or using administrative functions.

Vertical IDOR vulnerabilities: The attacker's goal is often to get data out as silently as possible. Sometimes this is more easily achieved if their account privileges elevate to those of an administrator for the system. The direction here is up. From a regular user, the attacker elevates their privilege up to that of an admin and performs those functions.

Object-level IDOR vulnerabilities: Logged in or not logged in, an attacker can access a data object they shouldn't be able to at any level. This could be an administrative function, server data, user data, or really anything.

Function-level IDOR vulnerabilities: Functions are the backbone of the application. What any given user can do within the application happens via various functions designed and implemented into the application. Often administrative functions are obscured from a user but can be inferred via various common paths or via comments.

One such function level IDOR is the ability to go to a subdomain and ask if /graphql is available. If /graphql is available, the graphql playground is launched, and the attacker has the entire database and schema at their disposal.

One of the assumptions here is that users are aware of the applications they have, the endpoints they contain, and what level of access is required for each endpoint and/or endpoint function. This is rarely the case.

Our typical customer comes to us because they have an API security issue. We tend to start at the same place with everyone, simply looking for APIs on the exterior attack surface via public records searches etc. It is rare for an organisation to look at the list and say they were aware of each subdomain, let alone each endpoint, that was accidentally left on.

All of the vulnerabilities listed in this advisory are valid and things we see on a daily basis. However, there are still breaches that start off with an endpoint the organisation was unaware of. Often it doesn't require authentication and is often very impactful in the data it discloses.

Once a customer is aware of the endpoints they have, instrumenting them for security posture becomes the next priority. This includes things like transaction monitoring, logging, and analytics, as well as ensuring the testing rigour all other applications face in your organisation includes these applications as well.

It is important for customers to discover, comply and protect their organisation's mission-critical APIs. A unified API protection (UAP) solution can empower security teams to discover their entire API footprint, understand their API security posture and protect their APIs from cyber-attacks.

Customers can identify the IDOR vulnerabilities that may be present within their APIs, empower security teams to work with their R&D teams to remediate critical IDOR vulnerabilities and protect in real-time against any API cyber-attacks.

General Partner Marcus Bartram at Telstra Ventures, an investor in Cequence, said: "The level of insight and technical depth that Cequence can bring to a customer to discover API vulnerabilities, monitor activity and protect the customer from both exploits and business logic abuse from API development to run time is one of the core reasons that we invested in the company."

"Cequence have continued to innovate and received industry recognition for their hard work and innovation, being ranked #1 in the latest API Security report by Datos Insights."