API-02 Broken User Authentication

Broken User Authentication is the second most critical API security threat on the OWASP API Security Top 10. It occurs when weaknesses in how an API authenticates users allow attackers to compromise accounts and make API requests as if they were a legitimate user.

What is user authentication?

Someone proving their identity to a computer system is called authentication. Authentication can happen in many ways but the traditional way is providing a username and password to prove identity digitally. New methods of providing stronger authentication such as 2-factor (2FA) or multi-factor (MFA) authentication have been created to provide more confidence in the identity of a computer user. Depending on the device used and the software running on that device, additional mechanisms may be available to validate identity claims. Most of the recent improvements have occurred for browsers and mobile devices.

Using an online retailer example, an attacker exploits weaknesses in the retailers API authentication to falsely claim to be an existing customer of the retailer. Once the attacker has successfully authenticated as that customer, they can take any action that that customer is allowed. For an attacker, actions like changing the shipping address and ordering merchandise with a ‘remembered’ credit card, changing the email address for the account, learning the order history are all possible attacks against the compromised customer. For instance, if embarrassing or sensitive items were purchased, the attacker could use these to harass or extort money from the target of their attack. If the API provides personal or sensitive data, those can be exposed by authentication weaknesses.

Why is it important?

If an API has authentication weaknesses, attackers can hijack existing user accounts and take any actions available to that API user. Since APIs are generally created for programmatic interaction e.g. not by humans, many of the protections that exist for mobile or browser interactions are not available. Additionally, if the weakness is global to the API, all user data is at risk.  For example, an API authentication flaw in a system designed to share criminal records between police forces in India allowed anyone to view or update criminal records. In this case, no authentication was required when calling the API.

Even when APIs require authentication, having confidence in the identity of the system or person using the API is essential to provide the appropriate level of access to users otherwise known as authorization. If attackers can assume the identity of the APIs users, they also gain the role and access of that user allowing access to all the API’s data.

Finally, some APIs provide methods to obtain authentication tokens by providing a username and password similar to logging into a website. The username and password (credential pair) is submitted to the API and an authentication token is provided in the response.  This token is used for all other requests made to the API. This pattern is common in APIs, especially older APIs, and is vulnerable to credential stuffing and password spraying attacks. These attacks against APIs have become so frequent and effective that large sites such as Github have removed ‘logins’ from their APIs and require tokens to be acquired with a browser workflow.

Example

Continuing with the online retailer example, below is a valid request of Alice to obtain an authentication token to use for other API calls:

Request

POST https://example.com/api/v2/customer/get_token HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: application/json

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin

{

'username': “alice”,

“password”: “#lubMv^cr25]UUJ/_%DkuxU|[”

}

Response

HTTP/1.1 200

Server: openresty/1.17.8.2

Date: Fri, 22 Jul 2022 03:25:30 GMT

Content-Type: application/json

Connection: keep-alive

Vary: Origin

Vary: Access-Control-Request-Method

Vary: Access-Control-Request-Headers

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

X-Frame-Options: DENY

{

'token': “eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZEBleGFtcGxlLmNvbSIsImlhdCI6MTY1ODQ2MDMzMCwiZXhwIjoxNjU4NTQ2NzMwfQ.m0ha0L89xuLpLlLlybcaD2SfKp23BZfe_Hjjs-PprCN2sDvxpmWAcemN5yOq-nhx78Iu8EzLIJbqqc1d-q10UA”

}

However, Mallory writes a small program to use usernames and passwords exposed on the Internet to attempt to gain valid tokens. His program loops through the list of credentials such as the example below for Bob:

Request

POST https://example.com/api/v2/customer/get_token HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: application/json

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin

{

'username': “bob”,

“password”: “letmein”

}

Looking at the response, it’s possible to tell when the credential pair was successful. With every successful credential guess, Mallory now has access to the API as if he was that customer. Since getting a large list of previously exposed credentials is easy for attackers, Mallory can make millions of guesses and gain multiple valid user tokens to use with further attacks against the API.

How to test

Attackers and penetration testers look for broken authentication vulnerabilities first by looking for APIs that allow ‘login’ or lack authentication completely. APIs that lack authentication can typically be found behind mobile clients and other uses where developers incorrectly believe only their client will call the API or that the API is somehow hidden.

What is a penetration tester?

A penetration or pen tester is someone who simulates the activities of a malicious attacker to discover security weaknesses in computer systems, applications, or APIs. The goal of pen testing is to discover and remediate security issues before malicious actors exploit them.

For APIs which allow ‘login’ by accepting a username and password combination to provide an authentication token, an attacker only has to automate the attack and have a list of usernames and passwords. A simple Internet search for ‘username and password list txt’ can find multiple lists of over 10 million records such as this one. Even attackers lacking basic programming skills have tools available which can automate the process such as THC-Hydra.

For APIs which require an authentication token, there are multiple known cryptographic and configuration weaknesses for API token mechanisms such as JSON Web Tokens (JWT). Simply using an authentication token and removing ‘login’ from an API does not mean the API is not vulnerable to broken user authentication.

How to defend

For APIs with ‘logins’, credential stuffing and password spraying attacks generate a large volume of traffic and will create a spike in failed login attempts. For defenders who monitor traffic and have telemetry data on failed login attempts, these attacks can be spotted easily. Additionally, the existing infrastructure can be utilized to block, de-authenticate or otherwise take action against the attacker. A common response to discovering an automated attack is to block the offending IP address for a period of time. For general guidance on preventing credential stuffing, there’s the OWASP Credential Stuffing Prevention Cheat Sheet.

For concerns around the strength of API authentication tokens, implementing secure software development practices including developer training can help prevent the creation of weak tokens. Many references exist such as the JSON Web Token Best Current Practices RFC and should be part of both the training and testing efforts. Beyond proactive controls, by monitoring API traffic it is possible to find cryptographic weaknesses in API tokens.

For new development or existing high risk APIs, removing API-based login completely should be considered. By forcing a browser-based workflow to obtain an authentication token, many of the controls and prevention mechanisms mentioned in the OWASP Credential Stuffing Cheat Sheet will be available which are not available to API calls. If API-based logins cannot be removed, careful monitoring of those API calls, including detailed audit logging, should be in place.

How Noname can help

Noname’s API security platform can help protect APIs with broken user authentication in multiple ways.  Noname provides a ‘shift left’ approach to security testing APIs so user authentication issues can be surfaced early in the development process. It provides granular testing capabilities with templated configurations for many popular CICD platforms. Noname also allows for rapid and highly targeted re-testing of vulnerabilities previously discovered allowing for rapid confirmation of developer fixes. Early testing in pre-production environments can reduce or eliminate broken user authentication issues before attackers have a chance to find them.

Noname also provides runtime protection that includes deep inspection and machine learning to analyze all traffic going to or from APIs. It understands multiple API types such as REST, GraphQL, SOAP, gRPC. By understanding API communication methods, deeply inspecting traffic and utilizing ML, Noname’s platform can notice that Mallory is trying credential stuffing or password spraying against an API. It also includes anomaly detection and can alert on a surge of authentication failures typical of probes for weak user authentication. When an attack is discovered, Noname allows for a flexible range of responses to the alerts raised.  At the most basic, it will provide alerts in the Noname web UI. More interesting are the integrations with ticketing systems available which allow Noname alerts to be triaged by the security team. Additionally, Noname can provide fully automated responses by interacting with existing infrastructure to take actions like blocking an IP for a period of time or de-authenticating a client’s token at the API gateway. Monitored APIs which lack authentication are automatically marked as vulnerable and displayed with the other security issues.

Finally, Noname’s platform provides API posture management capabilities. Leveraging Noname’s runtime monitoring, the platform will dynamically create an inventory of all APIS including those that include API-based login. Additionally, the platform passively monitors the cryptographic strength and use of authentication tokens. Noname inventories APIs based on the hostname, path/URI and HTTP method allowing for granular controls to be established across the entire API inventory. Beyond creating an inventory, data received and sent are auto-classified. The platform also allows for custom data types to be created to accommodate business-specific data. Using the auto-classified data, policies can be created to restrict sensitive data in API communications. For example, a policy to disallow credit card numbers from ever leaving an API could be created. Any policies on data are enforced by the platform’s runtime protection including policies around authentication token use.