Insights from a Leading API Security Vendor: Understanding the Joint Cybersecurity Advisory on IDOR Vulnerabilities by ACSC, CISA, and NSA – Source: securityboulevard.com

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) released a joint Cybersecurity Advisory on July 27, 2023, to warn vendors, designers, and developers of web applications and organizations using web applications about insecure direct object reference (IDOR) vulnerabilities also known as broken object level authorization (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, api.example.com/id/12345 has this issue, the user could just change the number on the end of the query string and api.example.com/id/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 like this. One of the glaring things that 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 way 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, they want to do this as silently as possible. Sometimes this is more easily achieved if their account privileges elevate to that 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 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, 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 api.example.com/graphql is available, the graphql playground is launched and the attacker has the entire database and schema at his/her disposal.

One of the assumptions here is that you are aware of the applications you 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 organization 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 that are listed in this advisory are valid and things that we see on a daily basis. However, we are still seeing breaches that start off with an endpoint the organization was unaware of, it often doesn’t require authentication and is often very impactful in the data it discloses. Once you are aware of the endpoints you have, instrumenting them for security posture becomes the next priority. This includes things like transaction monitoring, logging, analytics as well as ensuring the testing rigor all other applications face in your organization includes these applications as well.

Cequence can help customers to discover, comply, and protect their organization’s mission-critical APIs. The Cequence 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. Through Cequence, 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.

If you are interested in learning how Cequence can help you to defend against IDOR vulnerabilities that can exploit your organization’s APIs, just request an assessment today!

The post Insights from a Leading API Security Vendor: Understanding the Joint Cybersecurity Advisory on IDOR Vulnerabilities by ACSC, CISA, and NSA appeared first on Cequence Security.

*** This is a Security Bloggers Network syndicated blog from Cequence Security authored by Jason Kent. Read the original post at: https://www.cequence.ai/blog/cq-prime-threat-research/idor-vulnerability/