Lock Down APIs to Prevent Breaches – Source: www.darkreading.com

Web and mobile application developers need to take more care in creating secure applications, as attackers are increasingly testing Web application programming interfaces (APIs) to compromise cloud and mobile services.

A specific class of common API vulnerabilities, known as insecure direct object reference (IDOR), is especially pernicious because they are “hard to prevent outside the development process, and can be abused at scale,” 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) stated in a joint advisory at the end of July. IDOR vulnerabilities occur when an application allows information or Web resources to be accessed using a key or identifier but without properly checking authentication or authorization.

The joint government advisory stressed that API vulnerabilities frequently are easy to exploit and can be attacked using automation on a broad scale.

“These vulnerabilities are common and hard to prevent outside the development process since each use case is unique and cannot be mitigated with a simple library or security function,” the government advisory stated. “Additionally, malicious actors can detect and exploit them at scale using automated tools. These factors place end-user organizations at risk of data leaks —where information is unintentionally exposed — or large-scale data breaches — where a malicious actor obtains exposed sensitive information.”

Companies have already fallen prey to lax security in their Web applications. In 2021, vulnerabilities in the API for at least one popular monitoring application — often referred to as stalkerware — exposed call records, messages, photos, and other history. The same year, researchers at Pen Test Partners discovered that the API for Peloton fitness equipment had endpoints that could be used by unauthenticated attackers to collect information on subscribers — one well-known member being the current President of the United States.

The issues are not new, but have become increasingly important because APIs have become broadly deployed —not only throughout the Internet, but as a way to connect to IoT devices, cars, and vehicles, says Jason Kent, hacker-at-large for Cequence Security, an API security firm.

“The rapid adoption of APIs over the last couple of years really points to the fact that this is now the foundation of the Internet,” he says. “We’re sending telematic data all around as these things are functioning and talking to each other. We’re building this backbone of APIs that holds the world up, and the security of this is going to be extremely important moving forward.”

Web API Flaws are Common

Losses due to insecure Web APIs have rocketed skyward, with an analysis by Marsh McLennan estimating that US companies would lose between $12 billion and $23 billion due to API compromises in 2022.

The Open Worldwide Application Security Project (OWASP) released an updated top-10 list of API security issues in early July, with IDOR vulnerabilities — referred to as Broken Object Level Authorization (BOLA) flaws — adorning the list’s top spot. The class of API vulnerabilities accounts for about a quarter of those found in a typical bug bounty engagement, based on data from major services, says Paulo Silva, co-leader of the OWASP API Security Project.

“Based on my experience as an ethical hacker [and] pentester, I would say in the majority of the BOLA cases, authentication is in place: to exploit BOLA issues I need a valid user account,” he says, adding: “Assuming the authorization is implemented correctly, after breaking in you should only be able to access the resources your victim is allowed [or] has permission to.”

Many application try to make routes and endpoints — the address of an application resource — hard to guess by randomizing keys and identifiers, but that is only security through obscurity. An attacker who can capture the API address through monitoring traffic or some other approach will have an impact that is no less severe or unpleasant just because the API uses cryptographically strong, random values, Silva says.

“The fact that I don’t know what the previous or next identifier is doesn’t prevent the issue,” he says. “It doesn’t mitigate the risk either: as soon as I discover a valid identifier belonging to another user’s private resource I’ll be able to fetch it if the authorization mechanism doesn’t exist or isn’t working properly.”

Educate Developers, Monitor Applications

Developers should focus on educating themselves about secure design of Web applications and using analysis tools to check their code for common API flaws and misconfigurations. In addition, code that has already been deployed should go through a security analysis process, where the application owner creates a security design document, compares the application to that document, and uses real users to test the specification, says Cequence’s Kent.

“Watching somebody go through their live data and actually use the platform tends to give developers a much deeper view into what it is that they need to change,” he says. “You can also whether we are leaking credit card numbers, or social security numbers or any sort of sensitive data.”

In addition, adding a web application firewall can help both instrument the application and help developers protect against attacks for issues that they may not yet know about, says Tim Erlin, head of product at Wallarm, an API security firm.

“In an ideal world, IDOR vulnerabilities would be fixed directly in the affected application or API code, but in many cases the teams responsible for security don’t have direct control over that code,” he says. “CISA’s recommendation to implement a web application firewall should be a higher priority, and should explicitly include capabilities to detect and block attacks against APIs. Security teams need to know that they can take proactive action while they wait for developers, their own or a vendor’s, to fix discovered vulnerabilities.”