当用户输入进入 HTTP 响应头、Location…

适用于用户输入未经清洗进入 HTTP 响应头、重定向 Location、Set-Cookie 值或日志，需要用 CRLF（%0D%0A）探测头注入、响应拆分和后续利用链的场景。

适用场景

解决思路

1. 将 CRLF 视为 \r\n（Carriage Return + Line Feed，%0D%0A）；HTTP 头由 CRLF 分隔，若用户输入无清洗地反射到响应头，注入 CRLF 字符即可创建新头甚至响应体。
2. Java 服务且 %0D%0A / \r\n 被 WAF 拦截时，改用 瘍（U+760D，低字节 \r）和 瘊（U+760A，低字节 \n）注入真实 CRLF；可用于 Angus Mail / Jakarta Mail SMTP、Apache HttpClient 头、JDK HttpServer 响应和 ActiveJ HTTP，并考虑重启用 Jira CVE-2025-57733 和 JDK CVE-2026-21933 类问题。
3. 基础探测：在参数中注入 %0D%0ANew-Header:injected，例如 https://target.com/redirect?url=%0D%0AX-Injected:true，然后检查响应头中是否出现 X-Injected: true。
4. 双 CRLF 响应体注入探测：注入 %0D%0A%0D%0A<script>alert(1)</script>，观察两个连续 CRLF 是否结束头部并让后续内容进入响应体。
5. 利用 Set-Cookie 进行会话固定：注入 %0D%0ASet-Cookie:PHPSESSID=attacker_controlled_session_id，让受害者使用攻击者控制的会话 ID。
6. 通过响应体实现 XSS：注入 %0D%0A%0D%0A<html><script>alert(document.cookie)</script></html>。
7. 若响应会被 CDN 或代理缓存，则进行缓存投毒：注入头部/响应体，使其服务给所有用户，例如 GET /page?q=%0D%0AContent-Length:0%0D%0A%0D%0AHTTP/1.1%20200%20OK%0D%0AContent-Type:text/html%0D%0A%0D%0A<script>alert(1)</script>。
8. 在日志可见字段（如 User-Agent、Referer）注入 CRLF 伪造日志条目，例如 User-Agent: normal%0D%0A127.0.0.1 - admin [date] "GET /admin" 200。
9. 若过滤器阻止 %0D%0A，尝试单独 %0D、单独 %0A，或 Unicode 形式 %E5%98%8A%E5%98%8D。
10. 若 URL 只解码一次，使用双重编码：%250D%250A。
11. 若过滤器按字面剥离 \r\n，改用 URL 编码形式。
12. 若只在参数值中阻止 CRLF，尝试在参数名中注入。
13. Unicode/UTF-8 绕过：%E5%98%8A%E5%98%8D 在某些解析器中会被解码为 CRLF。
14. 双重 URL 编码绕过：%250D%250A 经服务器解码为 %0D%0A 后解释为 CRLF。
15. 仅 LF 的部分注入：%0A，某些服务器接受没有 CR 的 LF。
16. CRLF + 会话固定链：在重定向参数中注入 ?url=%0D%0ASet-Cookie:PHPSESSID=attacker_controlled_session_id，使 302 响应同时返回 Location 和注入的 Set-Cookie；受害者使用攻击者会话，攻击者可在其登录后劫持。
17. CRLF → XSS 链：使用双 CRLF 响应体注入 ?url=%0D%0A%0D%0A<script>alert(document.cookie)</script>，使 302 响应头结束后注入响应体脚本。
18. 302 Location 重定向劫持：注入 ?url=%0D%0ALocation:http://evil.com%0D%0A%0D%0A；某些服务器使用最后一个 Location 头，从而重定向到 evil.com。
19. 检查常见易受攻击模式：PHP 中 header("Location: " . $_GET['url']);（PHP < 5.1.2 易受攻击）。
20. 检查 Python：return redirect(request.args.get('next'))。
21. 检查 Node.js：res.setHeader('X-Custom', userInput);。
22. 检查 Java：response.setHeader("Location", request.getParameter("url"));。
23. 在重定向 URL 参数中注入 %0D%0A。
24. 在 Set-Cookie 名称/值路径中注入 %0D%0A。
25. 尝试双 CRLF 进行响应体注入 → XSS。
26. 测试编码绕过：双重编码、Unicode（%E5%98%8D%E5%98%8A）、仅 LF（%0A）。
27. 检查响应是否可缓存 → 缓存投毒。
28. 在 User-Agent / Referer 中测试日志注入。
29. 测试 CRLF + Set-Cookie 进行会话固定。
30. 验证 302 响应中的 Location 头是否可被注入。

适用边界 · 注意事项

• 不适用于用户输入不会进入 HTTP 响应头、Location、Set-Cookie 或日志文件的场景。
• 不适用于服务器/框架已严格拒绝头值中的 CR/LF 且不存在编码、Unicode 或解析差异，无法产生拆分效果时。
• 仅用于授权安全测试；未授权目标不应使用。