CRLF 注入是什么
CRLF 注入指的是用户输入里的回车换行没有被过滤，直接进入了响应头（Location、Set-Cookie 名称、自定义头取值）。换行符一旦进入头部，响应结构就可能被拆分，攻击者可以在响应中插入新的头部甚至响应体。验证要点是「结构变化」而不是「内容回显」：提交带换行编码的取值，对比原始响应与新响应的头部数量与内容差异即可。涉及共享缓存时，任何进一步验证都要先与客户确认窗口。
基本信息
| 常见入口 | 跳转参数、Cookie 名称、自定义响应头取值、日志回显 |
|---|---|
| 信号 | 响应头数量与内容异常、下游代理处理行为改变 |
| 编码形式 | 百分号编码的换行、其他等价编码方式 |
| 原则 | 只验证结构变化，不做缓存投毒 |
| 环境差异 | 中间代理可能对换行做规范化，结果依链路而异 |
典型使用场景
- Web 检查中的常规项，重点看跳转与重定向参数
- Cookie 写入相关的参数核查
- 排查「响应头异常增加」这类现象
- 评估修复方案：是否在写入响应头前统一过滤控制字符
- 与缓存类问题组合判断影响范围（需先约定验证窗口）
验证步骤
验证步骤
# 1. 找到进入响应头的输入，常见于跳转目标
curl -sI 'https://example.com/go?url=/home' # 记录原始响应头基线
# 2. 提交含换行编码的取值，观察响应头是否被拆分
curl -sI 'https://example.com/go?url=/home%0d%0aX-Test:%20injected'
# 3. 对比响应头数量与内容差异，记录现象（脱敏）
# 4. 不针对共享缓存做进一步动作；需要验证时先与客户确认窗口现象与判断
| 现象 | 含义 | 处置 |
|---|---|---|
| 响应头中新增了注入的头部 | 换行未过滤，头部被注入 | 列缺陷，建议过滤控制字符 |
| 返回 400 或请求被拒绝 | 存在输入校验 | 记录为已核查 |
| 响应体中出现异常内容 | 可能影响到响应结构 | 谨慎记录，避免扩大请求量 |
| 代理层规范化后无变化 | 链路中有规范化处理 | 说明验证位置与局限 |
若目标前面有 CDN 或共享缓存，任何进一步验证都要先与客户确认窗口：一旦标记被缓存，会影响真实用户。
结论要说明验证位置：从外网经代理访问与在内网直连服务的表现可能不同，同一输入在不同链路上结果不一样。