You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| API Specific : Exploitability **3**| Prevalence **2** : Detectability **2**| Technical **3** : Business Specific |
7
-
| Keys are the most popular API authentication mechanism but managing them correctly is not an easy task. Attackers have automatic tools to search for API keys on public repositories or mobile applications. | When authentication is based simply on keys, once the attacker gets access to valid tokens they can perform legitimate API requests. Although access can be logged and monitored, the ability to investigate and identify malicious activity is not a simple task. | The impact greatly depends on access tokens grants and can range from the exposure of sensitive data for a single user to full data access or even control over multiple systems and services. |
7
+
| 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 right. On top of that, the authentication mechanism is an easy target for attackers, since it’s exposed to everyone. These two points, makes the authentication component a fertile ground for many exploits. | 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. |
8
8
9
9
## Is the API Vulnerable?
10
10
11
-
The API is vulnerable if:
11
+
Authentication endpoints and flows are assets that need to be protected.
12
12
13
-
* Authentication only relies on access tokens.
14
-
* The same access token is valid for multiple APIs or API versions.
15
-
* Access tokens are tracked together with the source code on a version control
16
-
system or hard-coded in the client.
13
+
“Forgot password / reset passwords” should be treated the same way as authentication mechanisms.
14
+
15
+
An API is vulnerable if:
16
+
* Permits [credential stuffing][1] where the attacker has a list of valid usernames and passwords.
17
+
* Permits attackers to perform a brute force attack on the same user, without presenting captcha \ account lockout mechanism
18
+
* Permits weak passwords
19
+
* Sends sensitive authentication details, such as auth tokens and password in the URL.
20
+
* Doesn’t validate the authenticity of tokens
21
+
* Accepts unsigned / weakly signed JWT tokens ("alg":"none") / doesn’t validate their expiration date
22
+
* Uses plain text, encrypted, or weakly hashed passwords
23
+
* Uses weak encryption keys / API keys
17
24
18
25
19
26
## Example Attack Scenarios
20
27
21
28
## Scenario #1
22
29
23
-
A mobile application adds smartphone-controlled geolocation, remote start/stop
24
-
and lock/unlock capabilities to a vehicle with a compatible remote start unit.
25
-
By reverse engineering the mobile application an attacker finds hard-coded admin
26
-
credentials which can be used in place of a user's username and password to
27
-
communicate with the server endpoint for a target user's account. With these
28
-
credentials the attacker can learn the ___location of a target as well as gain
29
-
unauthorized control over the car.
30
+
[Credential stuffing][1], the use of [lists of known passwords][2], is a common attack.
31
+
If an application does not implement automated threat or credential stuffing
32
+
protections, the application can be used as a password oracle to determine if
33
+
the credentials are valid.
30
34
31
35
## Scenario #2
32
36
33
-
A company uses private repositories on a web-based hosting service for version
34
-
control. Access tokens to their internal APIs as well as cloud services are
35
-
tracked together with the source code and an attacker targeting this company
36
-
gains control over the private repository. Using the exposed access tokens the
37
-
attacker not only gets access to sensitive data but also control over some
38
-
services.
37
+
An attacker starts the password recovery workflow by issuing a POST request to
38
+
`/api/system/verification-codes` and by providing the username in the request
39
+
body. Next an SMS token with 6 digits is sent to the victim’s phone. Because the
40
+
API does not implement a rate limiting policy the attacker can test all possible
41
+
combinations using a multi-thread script, against the
42
+
`/api/system/verification-codes/{smsToken}` endpoint to discover the right token
43
+
within a few minutes.
39
44
40
45
## How To Prevent
41
46
42
-
* APIs that have access to sensitive data should use an additional form of
43
-
authentication in addition to API keys.
44
-
* API keys should have restrictions both for the applications (e.g. mobile app,
45
-
IP address) and the set of APIs they are valid for.
46
-
* API keys should be stored on a secure ___location such as a vault.
47
-
* A Configuration Management (CM) tool should be used and a clear configuration
48
-
management process should be defined.
47
+
* Make sure you know all the possible flows to authenticate to the API (mobile/web/deep links that implement one-click authentication/etc)
48
+
* Ask your engineers what flows you missed.
49
+
* Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither API keys .
50
+
* Don't reinvent the wheel in authentication, token generation, password storage. Use the standards.
51
+
* Credential recovery / forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting and lockout protections.
52
+
* Use the [OWASP Authentication Cheatsheet][3]
53
+
* Where possible, implement multi-factor authentication.
54
+
* 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.
55
+
* Implement [account lockout][4] / captcha mechanism to prevent brute force against specific users.
56
+
Implement weak-password checks.
57
+
* API keys should not be used for user authentication, but for [client app / project authentication][5].
0 commit comments