OWASP API Security Top 10 - Broken Authentication
Let us dive into the second item in the OWASP API Top 10 list: Broken Authentication. In this article, we look at a couple of attacks that fall into this category and also review the protection mechanisms. If you missed the first article in this series which discusses the Broken Object Level Authorization (OWASP API #1), you can find it here.
In simple terms, authentication is the process of verifying who a user is. An Authentication API endpoint serves as the entry point to the rest of the API. It is therefore important to treat it differently. First of all, it is the only open end-point (assuming all others are protected by authentication tokens). Second, if compromised, the rest of the API access control is off. Implementing a good layer of security for the API endpoint will avoid many attacks such as credential stuffing, brute force, and token stealing.
We can call an API is vulnerable to OWASP API #2 (Broken Authentication) if it:
Allows Bruteforce and Credential Stuffing attacks
Sends sensitive authentication details, such as auth tokens and passwords in the URL
Accepts weak JWT tokens, which are either unsigned, weakly signed, or not having invalid or too long expiration days
Uses plain text, non-encrypted, or weakly hashed passwords
Uses weak encryption keys
Allows authentication bypass due to misconfiguration
Unprotected APIs even though they are ‘internal’
Let us review Authentication attacks happened for real:
Android apps expose data through Google Firebase Databases
Firebase is a mobile and web application development platform from Google. Approximately 30 percent of Android apps on Google Play Store are using Firebase to develop and store the data.
The vulnerability as described in the article, a vulnerability is discovered in several apps which stored their data in Firebase: these apps exposed data publicly without implementing any authentication. The exposed databases were found by running a simple script which enumerates app resources for strings such as ‘.firebaseio.com’ which indicates that firebase is being used. Then a simple REST API by appending ‘/user.json’ to the above endpoint and sending a request returns the full database contents in JSON format if the database is exposed publicly. The exposed data included millions of records of PII data and other financial and health records as well.
Figure 1: Unauthenticated API calls to Publicly Exposed Firebase DB
SoundCloud Vulnerability: Lack of rate-limiting for authentication endpoint
Another example of authentication flaw is with online music platform SoundCloud, where authentication is enforced but the API endpoint does not implement account lockout based on failed login attempts thus allowing bruteforce via infinite number of API requests.
According to the explanation from Checkmarx security research team, the API endpoint resource api-v2.soundcloud.com/sign-in/password is responsible to authenticate and provide access token for further accessing other APIs. The only protection mechanism available was rate limiting but this was circumvented successfully by manipulating user_agent, device_id and signature parameter.
Few other well-known authentication vulnerabilities that have been identified not long ago include:
Also, one easy source for attackers to make use of authentication related attacks is the IoT devices where pre-configured credentials are used to authenticate against the manufacturer’s API endpoints. Compromising the authenticity of such devices is, therefore, easier.
One way to ensure protection against such attacks is to correctly implement authentication flows and integrate with 3rd party identity providers. There are several authentication schemes available to be used with APIs but OAuth2.0 is the popular choice for securing APIs, and OAuth2.0 combined with OpenID Connect (OIDC) provides the required level of authentication and authorization for APIs.
Test all possible ways to authenticate to an API. Make sure that there are negative tests in regard to authentication and authorization. Some examples are
passing invalid usernames and passwords
attempt to access protected resources without credentials
attempt to use invalid credentials, expired session tokens, provoke lockout of an account and validate the enforcement of locking logic/timeframe
Implement security questions and/or multi factor authentication as required.
Always use short-lived access tokens. With OAuth 2.0, the authorization server can issue a short-lived access token and a long-lived refresh token. This allows apps to obtain new access tokens without involving the user again, but also adds the ability for servers to revoke tokens easily.
To protect from brute force and credential stuffing attacks, stricter rate-limiting has to be enforced on APIs authentication requests. Also implement lockout of client/IP address whenever a threshold is crossed for authentication failures. All passwords must meet complexity requirements policy.
It is essential to enforce the above discussed protection schemes consistently across all published API products, especially as the API landscape rapidly evolves within an organization. CloudVector can help govern these authentication patterns with various policies that can :
Follow and alert for suspicious OAuth 2.0 authorization flows
Set up rate limit on APIs
Track Token expiry
Respond to suspicious activity with baseline traffic activity in place