sast-jwt

Name: sast-jwt
Author: utkusen

38installs56forks

How to install sast-jwt?

utkusen/sast-skills/sast-jwt

$npx -y skills add utkusen/sast-skills --skill sast-jwt

Installs into the current project.

Summary

Detect insecure JWT (JSON Web Token) implementations in a codebase using a two-phase approach: first map all JWT issuance and verification sites to understand the token lifecycle and signing configuration, then check each verification site for exploitable weaknesses such as algor

Files · 1

View on GitHub

SKILL.md

1	# JWT Vulnerability Detection
2
3	You are performing a focused security assessment to find insecure JSON Web Token (JWT) implementations. This skill uses a two-phase approach with subagents: recon (map the full JWT lifecycle — issuance, verification, and configuration) then analysis (identify every exploitable weakness in those verification sites).
4
5	Prerequisites: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.
6
7	---
8
9	## What is an Insecure JWT Implementation
10
11	JWTs consist of three Base64URL-encoded parts: `header.payload.signature`. The header declares the signing algorithm (`alg`), the payload carries claims (e.g., `sub`, `role`, `exp`), and the signature is a cryptographic proof of integrity. Vulnerabilities arise when the server trusts the token's own claims about how it was signed, fails to verify the signature at all, uses a guessable secret, or trusts attacker-controlled key material embedded in the token itself.
12
13	The core pattern: the server does not fully verify the JWT's authenticity and integrity before trusting its claims.
14
15	### What JWT Vulnerabilities ARE
16
17	1. Algorithm confusion — `alg: none`
18	The server accepts a JWT whose header declares `"alg": "none"`, bypassing signature verification entirely. An attacker crafts an arbitrary payload, sets `alg` to `none`, and omits the signature. If the library processes it, the forged token is accepted.
19
20	2. Algorithm confusion — RS256 → HS256
21	A server configured for RS256 (asymmetric: sign with private key, verify with public key) can be tricked into HS256 mode if the library allows the algorithm to be specified by the token. Since the public key is often retrievable, the attacker signs a forged token with HS256 using the server's public key as the HMAC secret. The server verifies the HMAC using the same public key and accepts the token.
22
23	3. Missing or disabled signature verification
24	The server decodes the JWT payload without actually verifying the signature. Common patterns:
25	- Python (PyJWT): `jwt.decode(token, options={"verify_signature": False})`
26	- Node.js (jsonwebtoken): `jwt.decode(token)` instead of `jwt.verify(token, secret)`
27	- Manual base64 decode of the payload with no signature check
28	- `algorithms=["none"]` accepted in the decode call
29
30	4. Weak or hardcoded HMAC secret
31	The server signs tokens with a short, guessable, or hardcoded secret (e.g., `"secret"`, `"password"`, `"changeme"`, `"jwt-secret-key"`). An attacker who captures a valid token can brute-force the secret offline with tools like `hashcat` or `jwt_tool`, then forge arbitrary tokens.
32
33	5. Embedded JWK (`jwk` header injection)
34	The token header contains an embedded JSON Web Key (`jwk` parameter). If the verification code trusts the embedded key to verify the token's own signature, an attacker generates their own key pair, signs a forged token with their private key, and embeds their public key in the header. The server verifies the signature using the attacker's embedded public key and accepts the token.
35
36	6. JKU / X5U header injection
37	The `jku` (JWK Set URL) or `x5u` (X.509 certificate URL) header value is used to fetch the verification key from a URL. If the server does not validate the URL against an allowlist, the attacker can point it to their own server hosting a crafted key set.
38
39	7. Key ID (`kid`) header injection
40	The `kid` header is used to look up the signing key, often from a database or the filesystem. If the `kid` value is interpolated into a SQL query without sanitization, it becomes an SQL injection vector. If it is concatenated into a file path, it becomes a path traversal vector.
41
42	8. Missing claim validation
43	- `exp` not checked → expired tokens remain valid forever
44	- `iss` (issuer) not checked → tokens issued by other services are accepted
45	- `aud` (audience) not checked → tokens intended for other services are accepted
46	- `nbf` (not-before) not checked → tokens used before their valid window
47
48	9. No token revocation
49	There is no token blacklist or revocation mechanism. Stolen or logged-out tokens remain valid until they expire. This matters most when token lifetimes are long.
50
51	### What JWT Vulnerabilities are NOT
52
53	Do not flag these as JWT vulnerabilities:
54
55	- IDOR: Changing a `user_id` claim to access another user's data is an authoriz

People who liked this also viewed

6 picks

Type

sast-jwt

38installs56forks

View on GitHub

How to install sast-jwt?

utkusen/sast-skills/sast-jwt

$npx -y skills add utkusen/sast-skills --skill sast-jwt

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# JWT Vulnerability Detection
2
3	You are performing a focused security assessment to find insecure JSON Web Token (JWT) implementations. This skill uses a two-phase approach with subagents: recon (map the full JWT lifecycle — issuance, verification, and configuration) then analysis (identify every exploitable weakness in those verification sites).
4
5	Prerequisites: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.
6
7	---
8
9	## What is an Insecure JWT Implementation
10
11	JWTs consist of three Base64URL-encoded parts: `header.payload.signature`. The header declares the signing algorithm (`alg`), the payload carries claims (e.g., `sub`, `role`, `exp`), and the signature is a cryptographic proof of integrity. Vulnerabilities arise when the server trusts the token's own claims about how it was signed, fails to verify the signature at all, uses a guessable secret, or trusts attacker-controlled key material embedded in the token itself.
12
13	The core pattern: the server does not fully verify the JWT's authenticity and integrity before trusting its claims.
14
15	### What JWT Vulnerabilities ARE
16
17	1. Algorithm confusion — `alg: none`
18	The server accepts a JWT whose header declares `"alg": "none"`, bypassing signature verification entirely. An attacker crafts an arbitrary payload, sets `alg` to `none`, and omits the signature. If the library processes it, the forged token is accepted.
19
20	2. Algorithm confusion — RS256 → HS256
21	A server configured for RS256 (asymmetric: sign with private key, verify with public key) can be tricked into HS256 mode if the library allows the algorithm to be specified by the token. Since the public key is often retrievable, the attacker signs a forged token with HS256 using the server's public key as the HMAC secret. The server verifies the HMAC using the same public key and accepts the token.
22
23	3. Missing or disabled signature verification
24	The server decodes the JWT payload without actually verifying the signature. Common patterns:
25	- Python (PyJWT): `jwt.decode(token, options={"verify_signature": False})`
26	- Node.js (jsonwebtoken): `jwt.decode(token)` instead of `jwt.verify(token, secret)`
27	- Manual base64 decode of the payload with no signature check
28	- `algorithms=["none"]` accepted in the decode call
29
30	4. Weak or hardcoded HMAC secret
31	The server signs tokens with a short, guessable, or hardcoded secret (e.g., `"secret"`, `"password"`, `"changeme"`, `"jwt-secret-key"`). An attacker who captures a valid token can brute-force the secret offline with tools like `hashcat` or `jwt_tool`, then forge arbitrary tokens.
32
33	5. Embedded JWK (`jwk` header injection)
34	The token header contains an embedded JSON Web Key (`jwk` parameter). If the verification code trusts the embedded key to verify the token's own signature, an attacker generates their own key pair, signs a forged token with their private key, and embeds their public key in the header. The server verifies the signature using the attacker's embedded public key and accepts the token.
35
36	6. JKU / X5U header injection
37	The `jku` (JWK Set URL) or `x5u` (X.509 certificate URL) header value is used to fetch the verification key from a URL. If the server does not validate the URL against an allowlist, the attacker can point it to their own server hosting a crafted key set.
38
39	7. Key ID (`kid`) header injection
40	The `kid` header is used to look up the signing key, often from a database or the filesystem. If the `kid` value is interpolated into a SQL query without sanitization, it becomes an SQL injection vector. If it is concatenated into a file path, it becomes a path traversal vector.
41
42	8. Missing claim validation
43	- `exp` not checked → expired tokens remain valid forever
44	- `iss` (issuer) not checked → tokens issued by other services are accepted
45	- `aud` (audience) not checked → tokens intended for other services are accepted
46	- `nbf` (not-before) not checked → tokens used before their valid window
47
48	9. No token revocation
49	There is no token blacklist or revocation mechanism. Stolen or logged-out tokens remain valid until they expire. This matters most when token lifetimes are long.
50
51	### What JWT Vulnerabilities are NOT
52
53	Do not flag these as JWT vulnerabilities:
54
55	- IDOR: Changing a `user_id` claim to access another user's data is an authoriz

People who liked this also viewed

6 picks

Type