offensive-oauth

Name: offensive-oauth
Author: SnailSploit

2.8kstars447forks

How to install offensive-oauth?

snailsploit/claude-red/offensive-oauth

$npx -y skills add SnailSploit/Claude-Red --skill offensive-oauth

Installs into the current project.

Summary

When this skill is active: 1. Load and apply the full methodology below as your operational checklist 2. Follow steps in order unless the user specifies otherwise 3. For each technique, consider applicability to the current target/context 4. Track which checklist items have been

Files · 1

View on GitHub

SKILL.md

1	# SKILL: OAuth Security Testing
2
3	## Metadata
4	- Skill Name: oauth-attacks
5	- Folder: offensive-oauth
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/oauth.md
7
8	## Description
9	OAuth 2.0 attack checklist: authorization code interception, redirect_uri bypass, CSRF on OAuth flow, state parameter abuse, open redirector chaining, token leakage via Referer, PKCE bypass, and scope escalation. Use when testing OAuth implementations in web apps or bug bounty.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`OAuth, OAuth 2.0, authorization code, redirect_uri bypass, OAuth CSRF, state parameter, PKCE bypass, scope escalation, token leakage, open redirector, OAuth attack`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28	# OAuth Security Testing
29
30	## Shortcut
31
32	- Check for improper redirect validation (open redirects)
33	- Test state parameter manipulation/absence
34	- Manipulate OAuth flows to bypass authentication
35	- Try URL path traversal in redirect_uri
36	- Hunt for client secret leakage in source code/repos
37	- Look for improper scope validation
38
39	## Mechanisms
40
41	- OAuth 2.0 authorizes limited access to resources via tokens; pair with OIDC for identity.
42	- Core Flows:
43	- Authorization Code (with PKCE for public clients)
44	- Client Credentials (service-to-service)
45	- Avoid Implicit and ROPC where possible
46	- Key Components:
47	- Resource Owner (user)
48	- Client (third-party app)
49	- Authorization Server (issues tokens)
50	- Resource Server (hosts protected resources)
51	- Tokens (access and refresh)
52	- Hardening Extensions:
53	- PAR (Pushed Authorization Requests), JAR (Request Objects), JARM (JWT-secured responses)
54	- Sender‑constrained tokens (DPoP, mTLS)
55	- `private_key_jwt` or mTLS client authentication for confidential clients
56
57	### OAuth/OIDC Considerations
58
59	- PKCE everywhere: Even with confidential clients/native apps; `code_verifier` must be required and validated.
60	- Nonce/state binding: For OIDC, ensure `nonce` is present and matched; `state` should be unguessable and tied to session.
61	- `redirect_uri` exact match: Enforce exact string match against pre-registered allowlist; no wildcards/path traversal.
62	- `aud`/`azp`/`iss` enforcement: Validate tokens strictly, including clock skew and JWKS `kid` rotation behavior.
63	- Front-channel logout/login CSRF: Validate logout CSRF; defend forced login to attacker accounts.
64	- ID Token vs Access Token: APIs must not accept ID tokens; check `token_type` and audience.
65	- Device Code & CIBA: Validate polling rate limits, code expiry, and binding of device/user codes.
66	- Refresh Token Rotation: Enforce reuse detection and global invalidation chains.
67	- PAR/JAR/JARM: Use to pin exact redirect_uri and inputs and to protect front-channel parameters.
68
69	### OAuth 2.1 Updates
70
71	- Implicit Flow Deprecated: Authorization servers should not support `response_type=token`
72	- Password Grant Deprecated: ROPC (Resource Owner Password Credentials) considered insecure
73	- PKCE Mandatory: Required for all OAuth clients including confidential clients
74	- Exact Redirect URI Matching: No more substring or prefix matching allowed
75	- Refresh Token Sender Constraint: Refresh tokens should be sender-constrained via DPoP or mTLS
76
77	### Financial-grade API (FAPI) Security
78
79	#### FAPI 1.0 Advanced Profile
80
81	- Signed Request Objects (JAR): Authorization requests as signed JWTs
82	- Hybrid Flow: Uses `response_type=code id_token` for additional security
83	- MTLS Client Authentication: Certificate-bound tokens
84	- JARM: JWT-secured authorization response mode
85	- Request Object Encryption: Sensitive parameters encrypted
86
87	#### FAPI 2.0 Security Profile
88
89	- Pushed Authorization Requests (PAR): POST request parameters to dedicated endpoint
90	- DPoP (Demonstrating Proof-of-Possession): Token bound to client's key pair
91	- Client Authentication: `private_key_jwt` or MTLS required
92	- Grant Management: Rich authorization requests and grant management API
93
94	```mermaid
95	graph TD
96	User[Resource Owner] -->\|Initiates flow\| Client
97	Client -->\|Authorization Request\| AuthServer[Authorization Server]
98	AuthServer -->\|Authentication\| User
99	User -->\|Approves access\| AuthServer
100	AuthServer -->\|Authorization Code\| Client
101	Client -->\|Code + Client Secret\| AuthServer
102	AuthServer -->\|Access Token\| Client
103	Client -->\|Access Token\| ResourceServer[Resource Server]
104	ResourceServer -->\|Protected Resource\| Client
105
106	style User fill:#b7b,stroke:#333,color:#333
107	style Client fill:#aae,stroke:#333,color:#333
108	style AuthServer fill:#9f9,stroke:#333,color:#3

People who liked this also viewed

6 picks

Type

offensive-oauth

2.8kstars447forks

View on GitHub

How to install offensive-oauth?

snailsploit/claude-red/offensive-oauth

$npx -y skills add SnailSploit/Claude-Red --skill offensive-oauth

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SKILL: OAuth Security Testing
2
3	## Metadata
4	- Skill Name: oauth-attacks
5	- Folder: offensive-oauth
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/oauth.md
7
8	## Description
9	OAuth 2.0 attack checklist: authorization code interception, redirect_uri bypass, CSRF on OAuth flow, state parameter abuse, open redirector chaining, token leakage via Referer, PKCE bypass, and scope escalation. Use when testing OAuth implementations in web apps or bug bounty.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`OAuth, OAuth 2.0, authorization code, redirect_uri bypass, OAuth CSRF, state parameter, PKCE bypass, scope escalation, token leakage, open redirector, OAuth attack`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28	# OAuth Security Testing
29
30	## Shortcut
31
32	- Check for improper redirect validation (open redirects)
33	- Test state parameter manipulation/absence
34	- Manipulate OAuth flows to bypass authentication
35	- Try URL path traversal in redirect_uri
36	- Hunt for client secret leakage in source code/repos
37	- Look for improper scope validation
38
39	## Mechanisms
40
41	- OAuth 2.0 authorizes limited access to resources via tokens; pair with OIDC for identity.
42	- Core Flows:
43	- Authorization Code (with PKCE for public clients)
44	- Client Credentials (service-to-service)
45	- Avoid Implicit and ROPC where possible
46	- Key Components:
47	- Resource Owner (user)
48	- Client (third-party app)
49	- Authorization Server (issues tokens)
50	- Resource Server (hosts protected resources)
51	- Tokens (access and refresh)
52	- Hardening Extensions:
53	- PAR (Pushed Authorization Requests), JAR (Request Objects), JARM (JWT-secured responses)
54	- Sender‑constrained tokens (DPoP, mTLS)
55	- `private_key_jwt` or mTLS client authentication for confidential clients
56
57	### OAuth/OIDC Considerations
58
59	- PKCE everywhere: Even with confidential clients/native apps; `code_verifier` must be required and validated.
60	- Nonce/state binding: For OIDC, ensure `nonce` is present and matched; `state` should be unguessable and tied to session.
61	- `redirect_uri` exact match: Enforce exact string match against pre-registered allowlist; no wildcards/path traversal.
62	- `aud`/`azp`/`iss` enforcement: Validate tokens strictly, including clock skew and JWKS `kid` rotation behavior.
63	- Front-channel logout/login CSRF: Validate logout CSRF; defend forced login to attacker accounts.
64	- ID Token vs Access Token: APIs must not accept ID tokens; check `token_type` and audience.
65	- Device Code & CIBA: Validate polling rate limits, code expiry, and binding of device/user codes.
66	- Refresh Token Rotation: Enforce reuse detection and global invalidation chains.
67	- PAR/JAR/JARM: Use to pin exact redirect_uri and inputs and to protect front-channel parameters.
68
69	### OAuth 2.1 Updates
70
71	- Implicit Flow Deprecated: Authorization servers should not support `response_type=token`
72	- Password Grant Deprecated: ROPC (Resource Owner Password Credentials) considered insecure
73	- PKCE Mandatory: Required for all OAuth clients including confidential clients
74	- Exact Redirect URI Matching: No more substring or prefix matching allowed
75	- Refresh Token Sender Constraint: Refresh tokens should be sender-constrained via DPoP or mTLS
76
77	### Financial-grade API (FAPI) Security
78
79	#### FAPI 1.0 Advanced Profile
80
81	- Signed Request Objects (JAR): Authorization requests as signed JWTs
82	- Hybrid Flow: Uses `response_type=code id_token` for additional security
83	- MTLS Client Authentication: Certificate-bound tokens
84	- JARM: JWT-secured authorization response mode
85	- Request Object Encryption: Sensitive parameters encrypted
86
87	#### FAPI 2.0 Security Profile
88
89	- Pushed Authorization Requests (PAR): POST request parameters to dedicated endpoint
90	- DPoP (Demonstrating Proof-of-Possession): Token bound to client's key pair
91	- Client Authentication: `private_key_jwt` or MTLS required
92	- Grant Management: Rich authorization requests and grant management API
93
94	```mermaid
95	graph TD
96	User[Resource Owner] -->\|Initiates flow\| Client
97	Client -->\|Authorization Request\| AuthServer[Authorization Server]
98	AuthServer -->\|Authentication\| User
99	User -->\|Approves access\| AuthServer
100	AuthServer -->\|Authorization Code\| Client
101	Client -->\|Code + Client Secret\| AuthServer
102	AuthServer -->\|Access Token\| Client
103	Client -->\|Access Token\| ResourceServer[Resource Server]
104	ResourceServer -->\|Protected Resource\| Client
105
106	style User fill:#b7b,stroke:#333,color:#333
107	style Client fill:#aae,stroke:#333,color:#333
108	style AuthServer fill:#9f9,stroke:#333,color:#3

People who liked this also viewed

6 picks

Type