Blog

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.

 

 

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.

Protection Mechanisms

 

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

Sekhar Chintaginjala

Sekhar Chintaginjala

Sekhar Chintaginjala is an experienced information security researcher who brings 15+ years of hands-on knowledge to the CloudVector team. He has proven expertise in the area of vulnerability research, security content development and leading teams for large global companies. At CloudVector, Sekhar is a member of the Security Research team and also leads efforts for new feature development that help protect from API abuses.