Skip to content

Commit 00e14f7

Browse files
emmanuelgautieremmanuelgautier
authored
Merge pull request #294 from cerberauth/update-jwtop-related-docs
docs: add missing docs and update docs related to jwt
2 parents e6a4f2e + 4d7b526 commit 00e14f7

12 files changed

Lines changed: 177 additions & 20 deletions

‎README.md‎

Lines changed: 1 addition & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -65,12 +65,6 @@ vulnapi scan curl [API_URL] [CURL_OPTIONS]
6565

6666
Replace `[API_URL]` with the URL of the API to scan, and `[CURL_OPTIONS]` with any additional curl options you wish to include.
6767

68-
Example:
69-
70-
```bash
71-
vulnapi scan curl -X POST https://vulnapi.cerberauth.com/vulnerable/api -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNTE2MjM5MDIyfQ."
72-
```
73-
7468
### Using OpenAPI Contracts
7569

7670
To perform a scan using OpenAPI contracts, execute the following command:
@@ -81,12 +75,6 @@ echo "[JWT_TOKEN]" | vulnapi scan openapi [PATH_OR_URL_TO_OPENAPI_FILE]
8175

8276
Replace [PATH_OR_URL_TO_OPENAPI_FILE] with the path or the URL to the OpenAPI contract JSON file and [JWT_TOKEN] with the JWT token to use for authentication.
8377

84-
Example:
85-
86-
```bash
87-
vulnapi scan openapi https://vulnapi.cerberauth.com/vulnerable/.well-known/openapi.json
88-
```
89-
9078
## Output
9179

9280
The CLI provides detailed reports on any vulnerabilities detected during the scan. Below is an example of the output format:
@@ -190,6 +178,7 @@ This scanner is provided for educational and informational purposes only. It sho
190178
## Thanks
191179

192180
This project used the following open-source libraries:
181+
* [jwtop](https://github.com/cerberauth/jwtop)
193182
* [SecLists](https://github.com/danielmiessler/SecLists)
194183
* [projectdiscovery/wappalyzergo](https://github.com/projectdiscovery/wappalyzergo)
195184

‎docs/index.mdx‎

Lines changed: 0 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -66,12 +66,6 @@ vulnapi scan curl [API_URL] [CURL_OPTIONS]
6666

6767
Replace `[API_URL]` with the URL of the API to scan, and `[CURL_OPTIONS]` with any additional curl options you wish to include.
6868

69-
Example:
70-
71-
```bash
72-
vulnapi scan curl -X POST https://vulnapi.cerberauth.com/vulnerable/api -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNTE2MjM5MDIyfQ."
73-
```
74-
7569
### Using OpenAPI Contracts
7670

7771
To perform a scan using OpenAPI contracts, execute the following command:

‎docs/vulnerabilities.mdx‎

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,8 @@ sidebar:
55
order: 100
66
---
77

8+
VulnAPI detects a wide range of API vulnerabilities, including those from the OWASP API Security Top 10.
9+
810
✅ = automated scan available
911

1012
| Name | OWASP | Severity | Automated Scan |
@@ -19,9 +21,9 @@ sidebar:
1921
| [JWT Audience cross service relay attack](./vulnerabilities/broken-authentication/jwt-cross-service-relay-attack) | API2:2023 Broken Authentication | High | |
2022
| [JWT Null Signature](./vulnerabilities/broken-authentication/jwt-null-signature) | API2:2023 Broken Authentication | High | ✅ |
2123
| [JWT KID Header Injection](./vulnerabilities/broken-authentication/jwt-kid-injection) | API2:2023 Broken Authentication | High | ✅ |
22-
| JWT Algorithm Confusion | API2:2023 Broken Authentication | High | ✅ |
24+
| [JWT Algorithm Confusion](./vulnerabilities/broken-authentication/jwt-algorithm-confusion) | API2:2023 Broken Authentication | High | ✅ |
2325
| [JWT Signature not verified](./vulnerabilities/broken-authentication/jwt-not-verified) | API2:2023 Broken Authentication | High | ✅ |
24-
| JWT Expired | API2:2023 Broken Authentication | High | |
26+
| [JWT Expired](./vulnerabilities/broken-authentication/jwt-expired) | API2:2023 Broken Authentication | High | |
2527
| Discoverable OpenAPI | API7:2023 Server Side Request Forgery | Info | ✅ |
2628
| Discoverable GraphQL Endpoint | API7:2023 Server Side Request Forgery | Info | ✅ |
2729
| [GraphQL Introspection Enabled](./vulnerabilities/security-misconfiguration/graphql-introspection) | API8:2023 Security Misconfiguration | Info | ✅ |
@@ -42,3 +44,5 @@ sidebar:
4244
| SSL Certificate Not Trusted | API8:2023 Security Misconfiguration | Medium | |
4345
| SSL Not Enforced | API8:2023 Security Misconfiguration | Medium | |
4446
| Directory Traversal | API10:2023 Unsafe Consumption of APIs | High | |
47+
48+
The JWT vulnerability scans are partially powered by the [CerberAuth JWTop](https://github.com/cerberauth/jwtop) project.

‎docs/vulnerabilities/broken-authentication/jwt-alg-none.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,8 @@ import { Tabs, TabItem } from '@/components/docs'
3939

4040
Accepting the "none" algorithm in a JSON Web Token (JWT) occurs when a JWT is signed with the "none" algorithm, it means there is no signature, making it easy for attackers to tamper with the token's content without detection. This can lead to unauthorized access and data manipulation.
4141

42+
For more details, you can refer to the [JWTop documentation on none algorithm](https://www.cerberauth.com/docs/jwtop/vulnerabilities/none-algorithm/).
43+
4244
## Example
4345

4446
Here is a valid JWT signed with RS512 algorithm:

‎docs/vulnerabilities/broken-authentication/jwt-algorithm-confusion.mdx‎

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
1+
---
2+
title: JWT Algorithm Confusion
3+
description: JWT Algorithm Confusion, also known as HMAC confusion attack, occurs when an attacker tricks a server into verifying a JWT using a symmetric algorithm (like HS256) instead of an asymmetric one (like RS256).
4+
---
5+
6+
import { Tabs, TabItem } from '@/components/docs'
7+
8+
<table>
9+
<tr>
10+
<th>Severity</th>
11+
<td>High</td>
12+
</tr>
13+
<tr>
14+
<th>CVEs</th>
15+
<td>
16+
<ul>
17+
<li><a href="https://www.cve.org/CVERecord?id=CVE-2016-5431">CVE-2016-5431</a></li>
18+
</ul>
19+
</td>
20+
</tr>
21+
<tr>
22+
<th>Classifications</th>
23+
<td>
24+
<ul>
25+
<li><a href="https://cwe.mitre.org/data/definitions/345.html">CWE-345: Insufficient Verification of Data Authenticity</a></li>
26+
<li><a href="https://cwe.mitre.org/data/definitions/347.html">CWE-347: Improper Verification of Cryptographic Signature</a></li>
27+
</ul>
28+
</td>
29+
</tr>
30+
<tr>
31+
<th>OWASP Category</th>
32+
<td>
33+
<a href="https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/">OWASP API2:2023 Broken Authentication</a>
34+
</td>
35+
</tr>
36+
</table>
37+
38+
JWT Algorithm Confusion, also known as HMAC confusion attack, occurs when an attacker tricks a server into verifying a JWT using a symmetric algorithm (like HS256) instead of an asymmetric one (like RS256). This typically happens when a server uses a public key (intended for RS256) as the secret for HS256 verification.
39+
40+
For more details, you can refer to the [jwtop documentation on HMAC Confusion](https://www.cerberauth.com/docs/jwtop/vulnerabilities/hmac-confusion/).
41+
42+
## Example
43+
44+
An application is expected to receive a JWT signed with an asymmetric algorithm like RS256. The server uses a public key to verify the signature.
45+
46+
If the application is vulnerable, an attacker can:
47+
1. Obtain the public key (which is often public).
48+
2. Create a new JWT with the algorithm header set to `HS256`.
49+
3. Sign the JWT using the public key as the HMAC secret.
50+
4. Send the forged token to the server.
51+
52+
The server, seeing `HS256` in the header, might use its public key as the secret to verify the HMAC signature, and if it doesn't strictly enforce the algorithm, the verification will succeed.
53+
54+
## How to test?
55+
56+
If you want to test only the "JWT Algorithm Confusion" vulnerability, you can use the following command:
57+
58+
<Tabs>
59+
<TabItem label="cURL">
60+
```bash
61+
vulnapi scan curl [url] -H "Authorization: Bearer [JWT]" --scans jwt.hmac_confusion
62+
```
63+
</TabItem>
64+
<TabItem label="OpenAPI">
65+
```bash
66+
echo "[JWT]" | vulnapi scan openapi [OpenAPI_Path_Or_URL] --scans jwt.hmac_confusion
67+
```
68+
</TabItem>
69+
<TabItem label="GraphQL">
70+
```bash
71+
vulnapi scan graphql -H "Authorization: Bearer [JWT]" --scans jwt.hmac_confusion [url]
72+
```
73+
</TabItem>
74+
</Tabs>
75+
76+
VulnAPI supports scanning against various types of other [vulnerabilities](../) as well.
77+
78+
## What is the impact?
79+
80+
The potential security impacts of JWT Algorithm Confusion are:
81+
82+
- **Full Authentication Bypass**: An attacker can forge tokens for any user, including administrative accounts.
83+
- **Unauthorized Access**: Gaining access to sensitive data and functionalities.
84+
- **Account Takeover**: Impersonating any user in the system.
85+
86+
## How to remediate?
87+
88+
- **Strict Algorithm Enforcement**: Always specify the expected algorithm(s) when verifying a JWT. Do not rely on the `alg` header from the token.
89+
- **Use Secure Libraries**: Use JWT libraries that are not vulnerable to this attack and ensure they are correctly configured.
90+
- **Separate Keys**: Use different keys for different purposes and ensure that public keys are only used for asymmetric verification.

‎docs/vulnerabilities/broken-authentication/jwt-blank-secret.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,8 @@ import { Tabs, TabItem } from '@/components/docs'
3535

3636
A vulnerability occurs when a JSON Web Token (JWT) is signed with an empty secret. In this scenario, the token lacks proper cryptographic protection, making it susceptible to manipulation. Attackers can modify the token's claims and content without detection, potentially leading to unauthorized access and data tampering.
3737

38+
For more details, you can refer to the [jwtop documentation on Blank Secret](https://www.cerberauth.com/docs/jwtop/vulnerabilities/blank-secret/).
39+
3840
## Example
3941

4042
Here is a valid JWT signed with HS256 algorithm:

‎docs/vulnerabilities/broken-authentication/jwt-cross-service-relay-attack.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,8 @@ description: A vulnerability arises when a Token is forged by the same service b
2727

2828
A vulnerability arises when a JSON Web Token (JWT) is signed by the same service but doesn't verify the issuer (the source of the token) and/or the audience (the intended recipient). This can lead to security risks, as it means an attacker could create a forged JWT with the same service signature and manipulate the issuer and audience fields. Without proper verification, the service may accept the forged token, potentially granting unauthorized access or compromising the system's security.
2929

30+
For more details, you can refer to the [jwtop documentation on Cross-Service Relay Attack](https://www.cerberauth.com/docs/jwtop/vulnerabilities/cross-service-relay-attack/).
31+
3032
![JWT Cross Service Relay Attack](./jwt-cross-service-relay-attack.png)
3133

3234
## Services impacted

‎docs/vulnerabilities/broken-authentication/jwt-expired.mdx‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
title: JWT Expired
3+
description: A vulnerability occurs when a JSON Web Token (JWT) is accepted by the server even after its expiration time (`exp` claim) has passed.
4+
---
5+
6+
import { Tabs, TabItem } from '@/components/docs'
7+
8+
<table>
9+
<tr>
10+
<th>Severity</th>
11+
<td>Medium</td>
12+
</tr>
13+
<tr>
14+
<th>Classifications</th>
15+
<td>
16+
<ul>
17+
<li><a href="https://cwe.mitre.org/data/definitions/287.html">CWE-287: Improper Authentication</a></li>
18+
<li><a href="https://cwe.mitre.org/data/definitions/613.html">CWE-613: Insufficient Session Expiration</a></li>
19+
</ul>
20+
</td>
21+
</tr>
22+
<tr>
23+
<th>OWASP Category</th>
24+
<td>
25+
<a href="https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/">OWASP API2:2023 Broken Authentication</a>
26+
</td>
27+
</tr>
28+
</table>
29+
30+
A vulnerability occurs when a JSON Web Token (JWT) is accepted by the server even after its expiration time (`exp` claim) has passed. JWTs are intended to be short-lived, and once they expire, they should no longer be considered valid for authentication or authorization.
31+
32+
## Example
33+
34+
A JWT contains an `exp` claim, which is a Unix timestamp indicating when the token expires:
35+
36+
```json
37+
{
38+
"sub": "1234567890",
39+
"name": "John Doe",
40+
"iat": 1516239022,
41+
"exp": 1516242622
42+
}
43+
```
44+
45+
If the current time is `1516243000` (which is after the `exp` time), the server should reject this token. If the server accepts it, it is vulnerable to using expired tokens.
46+
47+
## How to test?
48+
49+
To test if the server accepts expired tokens, you can obtain a valid token, wait for it to expire, and then try to use it. Alternatively, if you have the signing key, you can create a token that is already expired.
50+
51+
VulnAPI does not currently automate this scan. You can use tools like [jwtop](https://github.com/cerberauth/jwtop) to create expired tokens for manual testing.
52+
53+
## What is the impact?
54+
55+
The impact of accepting expired tokens includes:
56+
57+
- **Prolonged Window of Opportunity**: Attackers can use stolen tokens for a longer period.
58+
- **Bypassing Revocation**: If a user is logged out or their access is revoked, an expired token might still grant access if the server doesn't check the expiration.
59+
- **Session Hijacking**: Increased risk of session hijacking if tokens are valid for too long or indefinitely.
60+
61+
## How to remediate?
62+
63+
- **Strict Expiration Check**: Ensure that your JWT library or implementation strictly verifies the `exp` claim.
64+
- **Short-Lived Tokens**: Use short expiration times for access tokens (e.g., 15-60 minutes).
65+
- **Use Refresh Tokens**: Implement refresh tokens to allow users to obtain new access tokens without re-authenticating, while keeping access tokens short-lived.
66+
- **Clock Skew Consideration**: Allow for a small, reasonable clock skew (e.g., a few minutes) when verifying expiration, but do not ignore it entirely.

‎docs/vulnerabilities/broken-authentication/jwt-kid-injection.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,8 @@ import { Tabs, TabItem } from '@/components/docs'
2626

2727
The `kid` (Key ID) JWT header field is intended to tell the server which key to use for signature verification. When this value is passed unsanitized to a database query or a file system lookup, attackers can inject a payload that causes the server to use an attacker-controlled key, effectively allowing them to forge arbitrary tokens.
2828

29+
For more details, you can refer to the [jwtop documentation on KID Header Injection](https://www.cerberauth.com/docs/jwtop/vulnerabilities/kid-header-injection/).
30+
2931
VulnAPI tests two variants of this attack:
3032

3133
- **SQL Injection** — injects a SQL payload into `kid` (e.g. `' UNION SELECT 'secret' ...`) so that the database returns a known value as the key.

‎docs/vulnerabilities/broken-authentication/jwt-not-verified.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,8 @@ import { Tabs, TabItem } from '@/components/docs'
3434

3535
The "JWT Signature Not Verified" vulnerability occurs when a server accepts a JWT whose signature was created with a completely different (random) key. If the server returns the same successful response as it does for a legitimately signed token, it is not verifying the signature at all — meaning an attacker can craft any payload they want and the server will accept it.
3636

37+
For more details, you can refer to the [jwtop documentation on Signature Not Verified](https://www.cerberauth.com/docs/jwtop/vulnerabilities/signature-not-verified/).
38+
3739
## Example
3840

3941
VulnAPI takes your valid token, extracts its algorithm and claims, then re-signs it using a randomly generated key:

0 commit comments

Comments
 (0)