Learn about the Salt + CrowdStrike Falcon integration
Learn more
Authentication in APIs is a complex topic, with software and security engineers often having misconceptions about what its boundaries are and how to implement it correctly. To make things even more challenging, prompting users or machines for credentials and additional authentication factors may not always be possible in direct API communication and authentication mechanisms are easy targets for attackers, particularly if they are fully exposed or public. These two points make the authentication component potentially vulnerable to advanced attacks that include brute-forcing of authentication, credential stuffing and credential cracking.
Problems with authentication in APIs usually stem from two issues:
There are also several technical factors that lead to broken authentication in APIs. These are the most common:
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.
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 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.
Broken authentication is the second most critical API security threat listed in the OWASP API Security Top 10. Common examples of attacks targeting broken 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.
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.
In 2021, Salt analysis of the Parler data breach found that the social media platform’s authentication was at least partially absent, supporting the general consensus among hacktivists and media outlets. This flaw, along with other security flaws in the Parler platform, enabled the scraping of at least 70TB of data before the platform got shut down on January 11, 2021, as it became clear that participants in the storming of the Capitol six days before had used it to coordinate their activities.
Hacktivists found that at least one API endpoint was available without any authentication requirement and several 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 a Twilio integration that was later decommissioned. Allegedly, some of the hacktivists that took part in the scraping of the platform’s data used this to bypass multifactor (MFA) authentication during account creation and extract data. This was later disputed by the hacktivists, and Twilio representatives have also stated it was false. An MFA misconfiguration would further fuel the debate about whether the Parler data was truly public, but there isn’t enough forensic evidence to support either claim.
Most media outlets have deemed the Parler security issues to be the result of poor coding. Although poor design choices and coding patterns have most likely played a part, dismissing the types of issues that led to the Parler breach as simply “poor coding” perpetuates the friction amongst developers, engineers, and security practitioners.
Modern application development and systems design is incredibly complex, and it requires many individuals in both security and non-security roles to work in sync to get a large-scale application working without issue. The problem is worsened when you consider the modern digital supply chain and how organizations outsource elements of IT wholesale or per project. Bugs and vulnerabilities are inevitable. However, we can continue to learn from these mistakes to improve the state of application security and API security.
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.
To protect against broken 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.
.jpg)
%20(1).jpg)