API2:2019 Broken User Authentication

Overview

Authentication in APIs is a complex and confusing mechanism. Software and security engineers might have misconceptions about what are the boundaries of authentication and how to implement it correctly. In addition, the authentication mechanism is an easy target for attackers, since it’s exposed to everyone. These two points makes the authentication component potentially vulnerable to many exploits.

Description

There are two sub-issues: 1. Lack of protection mechanisms: APIs endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection 2. Misimplementation of the mechanism: The mechanism is used / implemented without considering the attack vectors, or it’s the wrong use case (e.g., an authentication mechanism designed for IoT clients might not be the right choice for web applications). Attackers can gain control to other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf, like money transactions and sending personal messages.

How to Prevent ?

Make sure you know all the possible flows to authenticate to the API (mobile/web/deep links that implement one-click authentication/etc.) Ask your engineers what flows you missed. Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither is API keys. Don't reinvent the wheel in authentication, token generation, password storage. Use the standards. Credential recovery/forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting, and lockout protections. Use the OWASP Authentication Cheatsheet. Where possible, implement multi-factor authentication. Implement anti-brute force mechanisms to mitigate credential stuffing, dictionary attack, and brute force attacks on your authentication endpoints. This mechanism should be stricter than the regular rate limiting mechanism on your API. Implement account lockout / captcha mechanism to prevent brute force against specific users. Implement weak-password checks. API keys should not be used for user authentication, but for client app/project authentication.

Example Attack Scenarios:

• Scenario #1:  Credential stuffing (using lists of known usernames/passwords), is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle (tester) to determine if the credentials are valid.

• Scenario #2:  An attacker starts the password recovery workflow by issuing a POST request to /api/system/verification-codes and by providing the username in the request body. Next an SMS token with 6 digits is sent to the victim’s phone. Because the API does not implement a rate limiting policy, the attacker can test all possible combinations using a multi-threaded script, against the /api/system/verification-codes/{smsToken} endpoint to discover the right token within a few minutes.