LAST UPDATED September 21, 2023
No. 2 on the 2023 OWASP Top 10 List of Critical API Security Risks, broken authentication is both a dangerous and common API security vulnerability.
OWASP says of broken user authentication: “The authentication mechanism is an easy target for attackers since it’s exposed to everyone. Although more advanced technical skills may be required to exploit some authentication issues, exploitation tools are generally available.”
How Do Broken Authentication Exploits Work?
In our last blog post, we covered BOLA attacks – or broken object level authorization. Authorization and authentication issues are similar, but have important differences. Authorization controls what you have access to, while authentication establishes who you are. Our SOC manager Neil Weitzel explains it this way, “Authentication is showing your ID or passport when you get to the airport. Authorization is showing your boarding pass before you get on the plane. Authentication establishes your identity; authorization establishes what plane you should be getting on, and what seat you’ve reserved.”
With that in mind, broken authentication exploits stem from APIs with improperly designed authentication mechanisms; or worse, from APIs with no authentication mechanisms at all. There are several methods of API authentication available, but it is most commonly managed through tokens today. Hence, many broken authentication exploits are the result of faulty token design or implementation.
Examples of attacks exploiting broken authentication include API enumeration attacks – which make high volumes of API requests with small changes – and credential stuffing attacks – which rapidly enter a list of stolen user credentials.
One common example of faulty token design is naming the tokens something obvious that lets an attacker know what the token is used for and, therefore, paints a little larger target on that particular token of the API request.
Lack of token expiration is another common design flaw that can be easily exploited. A token left unexpired is an ideal attacker target, basically an evergreen all-access pass to user data, PII, PHI, or whatever data the endpoint exposes.
Ultimately, developers using weak, known-vulnerable, or unhardened methodologies to create/handle tokens makes the work of an attacker easier.
OWASP offers this example:
In order to update the email address associated with a user’s account, clients should issue an API request like the one below:
PUT /account
Authorization: Bearer <token>
{ “email”: “<new_email_address>” }
Because the API does not require users to confirm their identity by providing their current password, bad actors able to put themselves in a position to steal the auth token might be able to take over the victim’s account by starting the reset password workflow after updating the email address of the victim’s account.
Broken authentication attacks can have serious consequences, including data leakage, privilege escalation, and account takeover.
Prevention of Broken Authentication
There are a few best practices in the development phase that can help prevent broken authentication vulnerabilities. Security in depth in this realm includes: threat modeling during design, code reviews during development, IDE-based code correctness testing, and pre-deployment static security testing.
Post deployment, security teams should pay special attention to API traffic, and endpoints should be armor-plated with a runtime security solution, analyzing API traffic for malicious intent.
How ThreatX Can Help
ThreatX can help both identify this vulnerability and block its exploitation. Due to our real-time, risk-based blocking, ThreatX can flag, watch, and, most importantly, block calls that attempt to exploit broken authentication.
Watching and Blocking Broken Authentication Exploitation
It can be difficult to detect if an attacker has exploited an instance of this vulnerability. Because this attack vector uses legitimate auth tokens, applications under attack often show no signs of an error.
However, ThreatX continuously monitors each unique client/user and detects probing or reconnaissance activity early in the kill chain. For example, we identify and flag resource ID enumeration, an indication of attempted exploitation of a broken authentication vulnerability. We also identify and flag other suspicious client activity, such as repeated error responses, indicative of reconnaissance and attack-surface mapping. If these behaviors reach a certain risk threshold or are observed in conjunction with other suspicious attacker behavior (as they frequently are), ThreatX blocks the attacker and records the events for later review.
Identifying Broken Authentication
In addition, ThreatX provides visibility into potentially vulnerable API endpoints. The details for each attack (as described above) are correlated to the targeted endpoint. In addition, failed requests are analyzed for various error conditions that indicate potential broken user authentication vulnerabilities.
How Our Approach Is Unique
Real-Time Blocking
Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify an attacking IP, but require security teams to try to model the complex behavior in a third-party WAF (or try to block one IP at a time after the fact). ThreatX doesn’t just tell you about your API vulnerabilities like broken authentication; we also block API attacks in real-time. ThreatX proxies and scans all inbound API traffic–in real time–identifying and blocking attacks.
ThreatX recognizes attacker behavior indicative of an attempt to exploit broken authentication, then flags and watches that user. This real-time monitoring enables ThreatX to execute advanced threat engagement techniques, such as IP interrogation, fingerprinting, and tarpitting. When a series of user interactions cross our default (or your customized) risk threshold, we block the attack.
Step One of N…
In many cases, attackers aren’t just going to attack with a broken authentication exploit; they’re going to string together a series of attacks over time, often using federated and sophisticated botnets. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker. Rather than requiring a single, significantly risky event or identifying a known signature, ThreatX analyzes behaviors from multiple vantage points. This lets the ThreatX Platform identify and block more threats, more accurately than competing API security tools.
Learn more about the role of bots in API attacks.
Less False Positives
As risk rises, ThreatX immediately blocks an attack – stopping the threat in its tracks. ThreatX’s blocking modes are designed to block malicious requests and deter suspicious entities from attacking your APIs, while allowing benign traffic and real users through. Legacy WAFs struggle with false positives because they only make blocking decisions based on rules, but attackers and legitimate users don’t always follow the rules. Sometimes a legitimate user who forgot their password looks like an attacker, and sometimes an attacker cycling through usernames and passwords looks like a legitimate user. ThreatX can tell the difference.
Learn more in A Security Practitioner’s Introduction to API Attack Protection. Or request a demo of the ThreatX solution.
