API2:2019 Broken User Authentication
In case you're not aware of our OWASP API Security Top 10 series, you can find the articles here. Most APIs, special those that support web front-ends or mobile applications, include several authentication-related endpoints. Based on our experience, quite often APIs fail to tackle brute force attacks, enforce strong password policies or properly validate JSON Web Tokens (JWT).
What is the issue?
Broken User Authentication comes in different flavors: weak password policy, authentication tokens in the URL, improper authentication tokens validation (e.g. JWT), user enumeration based on binary recover password endpoint response, missing brute-force attacks mitigation, etc.
The issue? API fails to protect user accounts and their assets against bad actors. It may lead to simple user accounts enumeration or complete account takeover, enabling attackers to access users’ private data or perform actions on victims’ behalf.
How does it look like?
Since Broken User Authentication has many flavors we will look into two of them that can be chained to compromise users’ accounts.
Let’s start with user account enumeration via the reset password endpoint. Often APIs provide an endpoint to support user reset password requests. What they often do wrong is returning a binary response regardless of whether the provided email address corresponds to an existing user account:
Replacing the email with something unlikely to exist, the API returns an HTTP error code: 404 Not Found.
Abusing this issue is trivial and can be automated for an arbitrary list of email addresses (e.g. site:pastebin.com email addresses leak). In the end, the attacker will have a list of email addresses associated with a user account.
With that list in hand, attackers can try to log in with one of those emails. Providing the wrong password the API returns an error HTTP status code:
But if they provide the correct password, the API returns a successful HTTP response (this is something attackers can figure out subscribing to a user account):
With a list of valid email addresses and knowing how the API login endpoint behaves, attackers can start testing arbitrary passwords until they find the right one (Credential Stuffing). For passwords, attackers can pick a word list such as those in Daniel Miessler SecLists repository. There are plenty of tools to automate this attack, but even a simple cURL command line will get the job done.
While automating a brute-force attack such as credential stuffing you may face API rate limiting issues. Most APIs do not implement rate-limiting (API4:2019 Lack of Resources & Rate Limiting) or it is not properly configured, allowing attackers to bypass it.
If for a single user account and after a reasonable number of failed login attempts the API does not reject subsequent login requests, then user authentication is broken and attackers are likely to succeed.
Where have we seen this issue lately?
Different issues lead to broken user authentication on APIs. The scenario described in this article is a simplified version of a reported SoundCloud issue whose details are available here, but the JSON Web Token Validation Bypass in Auth0 Authentication API is yet another example.
Unfortunately, user authentication issues in APIs are common. Following authentication best practices, using updated and actively maintained authentication libraries/packages/modules, implementing secure code review strategy, and frequent security audits, may help to prevent these issues, preventing the high business impact these issues usually represent.