1. 项目概述从两个看不见的字符说起做Web安全测试或者开发的朋友对SQL注入、XSS跨站脚本这些名词肯定不陌生但提起“CRLF注入”很多人可能会觉得有点陌生或者觉得它是个“古老”的、危害不大的小问题。我刚开始接触安全时也是这么想的直到在一次内部渗透测试中我们利用一个不起眼的跳转参数成功在目标管理后台植入了会话Cookie直接拿到了管理员权限这才让我彻底重视起这个看似简单的漏洞。CRLF注入全称是“回车换行注入”也有人叫它HTTP响应头拆分攻击。它的核心就是利用了HTTP协议中用于分隔数据的两个特殊控制字符回车和换行。攻击者如果能向HTTP响应头中注入这两个字符就能“欺骗”浏览器让它在原本应该只有一个头的地方错误地“拆分”出新的、由攻击者控制的HTTP头甚至直接开始写入响应体。这听起来有点抽象但它的危害链可以非常直接从会话固定、缓存投毒到绕过WAF的反射型XSS甚至为更复杂的攻击铺路。今天我就结合自己踩过的坑和实战经验把这个漏洞的原理、挖掘、利用和修复掰开揉碎了讲清楚。无论你是开发者想加固自己的应用还是安全爱好者想拓宽攻击面理解CRLF注入都是绕不开的一课。2. 核心原理深度拆解协议层面的“语法错误”要真正理解CRLF注入我们不能只停留在“注入\r\n”这个动作上必须深入到HTTP协议本身去看它为什么会被“欺骗”。这就像理解SQL注入你得先明白SQL语句是如何拼接和解析的。2.1 HTTP报文结构与CR/LF的分隔作用HTTP协议本质上是一种基于文本的协议客户端和服务器通过交换格式化的文本来进行通信。一份完整的HTTP响应报文可以简化理解为由三部分组成状态行例如HTTP/1.1 200 OK包含了协议版本、状态码和状态描述。响应头由多个Header-Name: Header-Value对组成每个头字段占一行用于传递元数据如内容类型、Cookie、缓存指令等。响应体即实际返回给浏览器的数据如HTML、JSON等。关键在于这三个部分之间以及响应头内部的各个字段之间是如何被区分开来的答案就是CR和LF这两个控制字符。CRCarriage Return回车符ASCII码为13在URL编码中是%0d在许多编程语言中用\r表示。它的本意是将打印头移回行首。LFLine Feed换行符ASCII码为10URL编码为%0a常用\n表示。它的本意是将纸张向上移动一行。在HTTP协议规范中明确规定每个响应头字段的末尾以一个CRLF序列结束。整个响应头部分的末尾以一个空行结束这个空行就是连续的两个CRLF即\r\n\r\n。所以一个合法的HTTP响应看起来是这样的为了清晰我用[CR][LF]直观表示HTTP/1.1 302 Found[CR][LF] Location: /dashboard[CR][LF] Set-Cookie: sessionIdabc123; HttpOnly[CR][LF] Content-Type: text/html[CR][LF] [CR][LF] htmlRedirecting.../html服务器告诉浏览器“头部分结束了后面是身体了。” 浏览器会严格遵循这个规则来解析报文。2.2 漏洞产生的根本原因未过滤的用户输入漏洞产生的土壤是应用程序将用户可控的、未经过滤的数据直接拼接到了HTTP响应头中。最常见的高危场景就是重定向。假设一个网站有一个登录后跳转的功能参数是redirect_to后端代码以Python Flask为例可能这样写from flask import Flask, redirect, request app Flask(__name__) app.route(/login) def login(): target request.args.get(redirect_to, /home) # 从用户输入获取跳转目标 # 危险操作未经过滤直接放入Location头 return redirect(target)当用户访问/login?redirect_to/dashboard时服务器会返回HTTP/1.1 302 Found Location: /dashboard ...这看起来很正常。但如果攻击者构造这样一个URL/login?redirect_to/dashboard%0d%0aSet-Cookie:%20evilinjected后端代码获取到的target变量值解码后就是/dashboard\r\nSet-Cookie: evilinjected。服务器将其拼接到Location头后发出的响应就变成了HTTP/1.1 302 Found Location: /dashboard Set-Cookie: evilinjected ...浏览器在解析时看到第一个\r\n认为Location头结束了。紧接着它看到了Set-Cookie: evilinjected它会忠实地将其解析为另一个独立的、合法的HTTP响应头这样一来攻击者就成功地向响应中注入了一个新的Cookie。实操心得这里有一个非常关键的细节。仅仅注入一个CRLF(%0d%0a)只能拆分出新的头但注入的内容还在“头区域”内。如果要直接开始写入响应体比如注入XSS代码就需要注入两个CRLF(%0d%0a%0d%0a)来提前结束整个头部分。例如redirect_to%0d%0a%0d%0ascriptalert(1)/script响应会变成头后面紧跟着脚本浏览器会将其作为HTML解析。2.3 与其他漏洞的关联与区别很多人容易把CRLF注入和XSS混淆或者觉得它只是XSS的一种前置条件。这里需要厘清与XSS的关系CRLF注入可以导致反射型XSS但它本身不是XSS。XSS的本质是让浏览器执行恶意脚本而CRLF注入是实现这个目的的一种手段。通过注入两个CRLF提前结束头部后面跟的JavaScript代码就会被当作响应体解析执行。这种XSS往往能绕过一些只检测请求体或URL中常见XSS载荷的WAF。与HTTP请求走私的区别HTTP请求走私是干扰服务器集群如前端代理与后端服务器对请求边界理解不一致的攻击。而CRLF注入是干扰单个服务器与客户端浏览器对响应报文结构的理解。前者发生在请求阶段利用的是请求头后者发生在响应阶段利用的是响应头。与CRLF日志注入的区别CRLF注入针对的是HTTP响应。还有一种类似的攻击叫“日志注入”攻击者将CRLF注入到用户代理、Referer等字段当服务器将这些信息记录到日志文件如文本格式的access.log时CRLF会导致日志文件换行可能破坏日志结构或注入恶意日志条目但这不影响浏览器行为。理解这些区别能帮助你在测试时更准确地判断漏洞类型和设计利用链。3. 漏洞挖掘与测试方法论知道了原理我们怎么在真实的网站中找到它呢盲目地在每个参数后面加%0d%0a是不可取的。高效的挖掘需要思路和技巧。3.1 高危功能点定位不是所有参数都值得测试。首先要锁定那些值会出现在HTTP响应头里的输入点。优先级从高到低如下重定向参数这是“皇冠上的明珠”。参数名常为redirect,redirect_to,return,return_to,next,url,target,r等。功能点包括登录/注销后跳转、错误页跳转、语言切换跳转、支付完成跳转等。设置HTTP头的参数一些应用允许通过参数动态设置某些头信息虽然不常见。例如某些缓存控制、自定义头等。文件名下载参数Content-Disposition头中的filename字段值如果来自用户输入也可能存在风险。例如download?filereport.pdf%0d%0a...。Header值回显点有些应用会将某些请求头如User-Agent,Referer的值原样输出到响应头或响应体中如果输出到响应头且过滤不严也可能存在风险但利用难度较高。3.2 手工测试与Payload构造定位到可疑参数后就可以开始测试了。我习惯用一个循序渐进的测试流程第一步基础探测先测试参数是否被原样输出到响应头。发送一个正常请求用Burp Suite或浏览器开发者工具查看原始HTTP响应确认目标参数值出现在哪个头字段通常是Location。第二步尝试注入CRLF构造Payload在参数值末尾添加%0d%0a即\r\n然后跟上一个测试头如Test-Header: injected。 示例/login?next/home%0d%0aTest-Header:%20injected发送请求后查看原始响应。如果响应中出现了Test-Header: injected这一行且它位于正常的响应头区域在空行之前那么恭喜漏洞存在第三步验证危害谨慎操作确认漏洞存在后可以尝试构造有实际危害的Payload来验证严重等级。务必在授权测试的范围内进行。注入Cookie会话固定next/dashboard%0d%0aSet-Cookie:%20sessionidattacker_controlled_value%3b%20Path/如果成功浏览器会收到并保存这个Cookie。攻击者可以诱导用户点击此链接从而将用户的会话固定为攻击者已知的值。注入XSS需两个CRLFnext%0d%0a%0d%0ascriptalert(document.domain)/script这个Payload会先注入一个CRLF结束当前的Location头如果存在再注入一个CRLF结束整个头部后面的script标签就会被当作响应体解析。注意如果原响应已经有Content-Type: text/html或者浏览器会进行容错解析XSS就会触发。拆分响应HTTP响应拆分 这是更高级的技巧注入两个CRLF后再伪造一个完整的HTTP响应。例如next%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Length:%20100%0d%0aContent-Type:%20text/html%0d%0a%0d%0ah1Hacked/h1...这可能会让浏览器认为收到了两个响应导致响应劫持但现代浏览器对此的容错和处理机制比较复杂成功率不如前两种高。注意事项在测试XSS或响应拆分时浏览器的缓存机制可能会干扰你的判断。因为服务器可能返回了恶意响应但浏览器缓存了之前正常的响应。务必在测试时使用无痕模式并勾选开发者工具Network面板下的“Disable cache”选项。3.3 自动化工具辅助与流量分析手工测试虽然精准但效率低。可以结合工具Burp Suite Scanner专业版的主动扫描器能够检测CRLF注入漏洞。定制化爬虫与扫描器使用grep或自定义脚本在爬取网站时重点识别包含redirect、next等关键词的链接和表单然后自动附加测试Payload。流量日志分析在访问日志中搜索%0d、%0a、\r、\n等字符是发现有人正在对你站点进行CRLF注入测试的迹象。即使使用工具也强烈建议对工具报告的问题进行手工验证因为工具可能存在误报如参数值被编码或截断和漏报如漏洞触发路径复杂。4. 实战利用场景与案例剖析找到漏洞只是第一步理解它能用来做什么才能评估其真实风险。CRLF注入的利用场景远不止弹个警告框那么简单。4.1 场景一会话固定攻击这是CRLF注入最经典、危害也最直接的利用方式。攻击流程攻击者发现一个存在CRLF注入的跳转链接例如https://victim.com/login?next/profile%0d%0aSet-Cookie:%20sessionfixed_by_attacker%3b%20Path/攻击者将这个链接通过邮件、论坛、社交工程等方式发送给受害者用户。用户点击链接访问victim.com。服务器返回的响应中包含了攻击者注入的Set-Cookie: sessionfixed_by_attacker头。用户的浏览器接收到这个响应会设置这个名为session、值为fixed_by_attacker的Cookie。随后当用户在该网站进行登录或其他需要会话的操作时浏览器会自动携带这个被固定的Cookie。攻击者由于知道这个Cookie值(fixed_by_attacker)他就可以直接在浏览器中设置相同的Cookie从而以该用户的身份登录系统无需知道密码。关键点这种攻击成功的前提是目标网站使用自定义的Cookie机制如session而非框架提供的、带有签名和时效性的安全Session机制。对于现代框架如Django、Flask使用Flask-Login、Spring Security等其默认的Session Cookie是经过签名加密的攻击者无法预测或固定因此能有效防御此类攻击。但许多老旧系统或自定义认证逻辑的网站仍可能中招。4.2 场景二绕过WAF的反射型XSS很多Web应用防火墙对XSS的检测主要集中在查询参数、请求体等“传统”的输入点。对于HTTP响应头中的注入检测规则可能不那么完善。案例 一个网站有跳转功能并且对script、onerror等常见XSS标签和事件处理程序进行了过滤或WAF拦截。但是它对CRLF字符\r\n的过滤可能不严格。 攻击者可以构造Payloadnext%0d%0a%0d%0aimg%20srcx%20onerroralert(1)这个Payload里没有script标签而是使用了图片加载错误的XSS向量。由于注入发生在Location头之后并且通过两个CRLF提前结束了头部后面的img标签直接进入响应体。WAF可能只检查next参数的值本身而不会将其与整个HTTP响应结构关联起来进行检测从而成功绕过。利用链扩展注入的XSS可以不是简单的alert而是窃取Cookie、发起CSRF请求、进行键盘记录等危害极大。4.3 场景三缓存投毒与Web缓存欺骗这是一个相对高级的组合利用技巧需要结合特定的服务器或CDN缓存配置。思路攻击者找到一个CRLF注入点可以注入任意HTTP头。攻击者注入一个影响缓存的头例如X-Forwarded-Host: attacker.com或X-Host: attacker.com。有些缓存代理如Varnish、某些CDN会根据这些头来区分缓存键。同时攻击者注入两个CRLF并跟上恶意内容如恶意JavaScript。当缓存服务器如CDN看到这个响应时它可能根据被污染的X-Forwarded-Host头将响应缓存到attacker.com这个缓存键下。当其他正常用户访问网站时他们的请求可能因为某些原因如携带了特定的头命中了被攻击者污染的缓存条目从而接收到恶意内容。Web缓存欺骗另一种变体是攻击者注入一个头使得包含用户敏感信息如个人资料页的响应被缓存到一个公开可访问的URL上从而造成信息泄露。这需要应用逻辑和缓存规则的特定配合。4.4 场景四请求走私等高级攻击的跳板CRLF注入有时可以作为其他复杂攻击的入口。例如在极少数情况下如果攻击者能够同时污染请求和响应这需要更特殊的条件CRLF注入可能与HTTP请求走私产生交集。但更常见的是它作为初步漏洞帮助攻击者设置特定的Cookie或头信息为后续的CSRF、点击劫持等需要特定上下文才能成功的攻击创造条件。5. 漏洞修复与防御指南对于开发者来说知道了攻击原理修复就有的放矢了。修复的核心原则是对用户输入进行严格的规范化、验证和过滤确保其不会被解释为HTTP协议的控制结构。5.1 输入验证与过滤白名单优先这是最直接有效的方法。严格白名单验证对于跳转URL最佳实践是使用白名单机制。只允许跳转到预先定义好的、安全的内部URL列表中的地址。# Good: 白名单验证 ALLOWED_REDIRECTS [/home, /dashboard, /profile] def safe_redirect(target): if target in ALLOWED_REDIRECTS: return redirect(target) else: return redirect(/home) # 或返回错误页过滤CRLF字符如果无法使用白名单必须对输入进行过滤。移除或转义所有CR(\r,%0d)、LF(\n,%0a)字符。# Good: 过滤CRLF import re def sanitize_redirect(target): # 移除所有CR和LF字符 cleaned_target re.sub(r[\r\n], , target) # 还可以考虑移除其他控制字符 # cleaned_target re.sub(r[\x00-\x1f\x7f], , cleaned_target) return cleaned_target注意不要只过滤\r\n序列要分别过滤\r和\n因为攻击者可能只注入其中一个。URL验证与规范化确保输入是一个合法的、相对路径或绝对路径且限定为当前域。可以使用标准库进行解析和验证。from urllib.parse import urlparse def validate_redirect_url(url, allowed_domains[victim.com]): parsed urlparse(url) # 只允许相对路径或无网域绝对路径或指定域名的绝对路径 if not parsed.netloc: # 相对路径 return url elif parsed.netloc in allowed_domains: return url else: return / # 非法域名重定向到首页5.2 安全的编程实践与框架使用使用框架的安全重定向函数现代Web框架如Django的django.utils.http.url_has_allowed_host_and_scheme, Flask的url_for结合next参数的安全处理通常内置了更安全的跳转逻辑。务必使用它们而不是手动拼接字符串。# Flask 示例使用 url_for 生成安全的内链 from flask import url_for, redirect app.route(/login) def login(): next_page request.args.get(next) if next_page and not is_safe_url(next_page): # 自定义安全检查函数 next_page None return redirect(next_page or url_for(index)) # 回退到安全地址避免将用户输入直接放入HTTP头从根本上审视代码是否有必要将用户输入放入Location,Set-Cookie,Content-Disposition等头中能否用其他方式实现设置安全的Cookie属性即使遭遇注入通过为Cookie设置HttpOnly、Secure、SameSiteStrict/Lax属性可以极大增加攻击者利用的难度如阻止JavaScript窃取Cookie防止跨站请求伪造等。5.3 输出编码与上下文感知上下文相关的输出编码如果用户输入必须回显到HTTP头中需要根据HTTP头的上下文进行编码。对于头值通常需要过滤控制字符并对特殊字符进行适当的转义。但最好的办法仍然是避免直接回显。安全头配置部署Content-Security-Policy可以缓解CRLF注入导致的XSS危害。设置X-Content-Type-Options: nosniff可以防止浏览器MIME类型嗅探在某些情况下增加利用难度。5.4 运维与安全设备层面Web应用防火墙配置WAF规则检测请求中是否包含编码或明文的CRLF字符%0d%0a,\r\n尝试注入到敏感参数如重定向参数中。代码审计与自动化扫描将CRLF注入作为安全代码审计和自动化漏洞扫描的必查项。在CI/CD流程中集成SAST工具。安全培训让开发人员了解CRLF注入的原理和危害在编写涉及重定向和HTTP头操作的代码时保持警惕。6. 常见问题与排查技巧实录在实际测试和修复过程中你会遇到各种各样的问题。这里记录一些我踩过的坑和解决方法。6.1 测试时遇到的“假阴性”与“假阳性”问题1我注入了%0d%0a但响应里没看到新头是没漏洞吗不一定可能是以下原因服务器端过滤应用或中间件如Web服务器、WAF过滤了CRLF字符。尝试双编码%250d%250a或使用其他编码变体如UTF-7等看是否能绕过。URL解码位置参数可能在经过多层处理后才被拼接到头部而其中某一层进行了URL解码。尝试直接注入明文的\r\n在Burp Repeater中直接修改原始请求体。值被截断输入长度可能有限制。尝试缩短Payload或检查是否有长度过滤。位置不对你注入的参数可能根本不会出现在响应头中。重新确认参数功能。问题2我看到了注入的头但浏览器好像没生效浏览器标准化现代浏览器在解析HTTP响应时会对头部进行标准化处理。例如它们可能将单个LF(\n)也视为换行或者将CRLF标准化。但这不影响漏洞存在因为攻击可能针对的是解析响应而非浏览器如中间代理、日志分析系统。缓存如前所述清空浏览器缓存或使用无痕模式。HTTPS与HSTS如果你注入了一个Set-Cookie头但没有Secure属性而网站是HTTPS且启用了HSTS浏览器可能会拒绝设置不安全的Cookie。问题3扫描器报告了CRLF漏洞但手工验证不了误报扫描器可能将其他行为如服务器错误返回多行信息误判为CRLF注入。务必手工验证。条件竞争或状态依赖漏洞可能只在特定条件下触发如用户未登录时。检查应用状态。6.2 修复后如何验证修复代码上线后需要进行回归测试正向测试使用修复前的攻击Payload进行测试确认漏洞已不存在。响应中不应再出现注入的头或内容。功能测试确保正常的重定向功能仍然工作。例如/login?next/dashboard应该能正确跳转到/dashboard。边界测试尝试各种边缘情况输入超长字符串。输入包含各种特殊字符但不含CRLF的字符串看是否被正确编码或拒绝。尝试使用不同的编码如UTF-8, UTF-16和空字节等。自动化测试将CRLF注入测试用例加入自动化安全测试套件。6.3 高级绕过技巧仅供防御参考了解攻击者可能使用的技巧才能更好地防御多重编码%0d-%250d-%25250d。如果服务器进行多次URL解码可能被绕过。使用不同换行符在某些上下文中只过滤了\r\n但没过滤单独的\r或\n。尝试%0d,%0a。利用Unicode或特殊字符某些Unicode字符在标准化后可能变成控制字符如%u000d,%u000a或者利用一些语言/库的字符串处理特性。注入到其他头字段除了Location检查其他可能回显用户输入的头如自定义头、X-Forwarded-For如果错误地回显到响应中等。防御的关键在于实施深度防御在输入点过滤、在输出点编码、使用安全框架、配置安全头。没有一劳永逸的银弹但多层防护能极大降低风险。最后我想说的是CRLF注入虽然原理简单但它像一面镜子照出了我们在处理用户输入时的粗心大意。在Web安全的世界里永远不要信任任何来自客户端的输入这句话值得刻在每一个开发者的脑子里。每一次重定向每一次将用户数据输出到HTTP头都问问自己“我过滤CRLF了吗” 这个简单的习惯就能挡住一大批潜在的攻击。