Authentication in APIs is a complex and confusing topic. Software and security engineers might have misconceptions about what the boundaries of authentication are and how to correctly implement it. Prompting users or machines for credentials and additional authentication factors may also not be possible in direct API communication. In addition, authentication mechanisms are easy targets for attackers, particularly if the authentication mechanisms are fully exposed or public. These two points make the authentication component potentially vulnerable to many exploits. Advanced attacks that target authentication include brute-forcing (of authentication), credential stuffing and credential cracking.
Authentication in APIs has two sub-issues:
Technical factors leading to broken authentication in APIs are numerous and include:
An attacker who is able to successfully exploit vulnerabilities in authentication mechanisms can take over user accounts, gain unauthorized access to another user’s data, or make unauthorized transactions as another user. Similarly, APIs may be designed explicitly for machine communication, or direct API communication. An attacker who compromises that authentication mechanism or authenticated session can potentially gain access to all of the data that machine identity is entitled to access. There are also variants of this type of attack in cloud-native design with compromises of workload authentication and server-side API metadata services.
Common examples of attacks targeting broken user authentication include API enumeration and brute-forcing attacks that make high volumes of API requests with minor changes. These attacks may also target broken or weak authentication.
As an example, password recovery mechanisms often send an SMS to a user’s phone with a reset token consisting of a series of numbers. An attacker can initiate a password reset, and if the API does not implement rate limiting, the attacker can enumerate (or “guess”) the password reset token until they get a successful response. Depending on the throughput of the target API endpoint, an attacker may be able to iterate through thousands or millions of different combinations within a few minutes.
https://salt.security/blog/unpacking-the-parler-data-breach
In 2021, Salt analysis of the Parler data breach and the general consensus of media outlets and hacktivists found that Parler’s authentication was at least partially absent. This flaw, along with other security flaws in the Parler platform, enabled the scraping of at least 70TB of data. Based on what the hacktivist shared publicly, at least one endpoint was available without authentication which provided access to user data without requiring authentication. In Parler’s case, these APIs likely were not intended to be anonymous, public APIs. The APIs allowed direct access to Parler user profile information and user content, including message posts, images, and videos. It is unlikely that Parler would have intended or configured these APIs and pages to be accessible without authentication.
Some reports indicated there was a security misconfiguration as a result of Twilio integration that was later decommissioned. Allegedly, some of the archivists used this to bypass multifactor (MFA) authentication during account creation and extract data. The issue was later disputed by the hacktivist, and Twilio representatives have also stated it was false. An MFA misconfiguration would further fuel the debate whether the Parler data was truly public and Parler APIs were lacking authentication.
Traditional security controls like WAFs don’t typically enforce authentication at a granular level and may only verify presence of a session identifier or authentication token in a given request. API gateways may enforce authentication as part of API management access control policies, but that presumes owning teams have defined policy appropriately. There is often an operational breakdown between teams creating APIs, teams publishing APIs, and teams securing APIs. Even still, API gateways lack understanding of what authentication is proper for an API in a given use case. Traditional security controls also lack capabilities to track attack traffic over time, which is necessary to decipher the different forms of advanced attacks targeting authentication such as credential stuffing and credential cracking. They will often rely on excessive API consumption rates to identify basic brute-force attack attempts.
In order to protect against broken user authentication attacks, an API security solution must be able to profile the typical authentication sequence for every API flow. The solution can then detect abnormal behavior such as missing credentials, missing authentication factors, or authentication calls that are out of sequence. Determining the baseline and identifying abnormal behavior can only be done by analyzing large amounts of production API traffic. This form of analysis is critical for mitigating advanced attacks that target authentication such as credential stuffing and credential cracking.
Previous post:
API1:2019 Broken Object Level Authorization
Next posts:
API3:2019 Excessive Data Exposure
API4:2019 Lack of Resources & Rate Limiting
API5:2019 Broken Function Level Authorization
