PHP Header注入漏洞原理与防御：从CRLF到响应拆分实战

1. 先搞懂Header注入从一个线上事故说起去年接手一个老PHP项目的代码审计翻到文件下载模块时我看到这样一段代码?php $filename $_GET[file]; header(Content-Type: application/octet-stream); header(Content-Disposition: attachment; filename . $filename); readfile(/data/files/ . $filename);乍一看好像没啥问题Content-Disposition里拼了文件名readfile去读真实文件。但当我尝试在URL里传入%0d%0aSet-Cookie: sessionidadmin时服务端返回的响应头里多了一行Set-Cookie整个响应结构被改写了。也就是说文件名参数里夹带的CRLF字符直接穿透到了HTTP响应头里——这就是PHP开发里经常被忽视的Header注入漏洞。这个漏洞在很多PHP项目里都存在尤其是老项目、二次开发项目。它不像SQL注入那么“有名”但带来的危害一点也不小轻则把用户重定向到钓鱼页面、固定会话重则配合缓存服务器污染大量用户的页面。对PHP开发者和安全测试人员来说这是必须掌握的一类问题。这篇文章不绕弯子直接从原理讲起把常见入口、复现方法、防御姿势全部过一遍。我会尽量写细遇到的实际坑也会如实说出来方便你遇到问题时能直接照着排查。1.1 HTTP响应头是怎么“断行”的要理解Header注入得先回到HTTP协议的最底层。HTTP报文无论是请求还是响应都由“起始行 头部字段 空行 消息体”组成。头与头之间用CRLFCarriage Return Line Feed即\r\n分隔头和体之间用两个连续的CRLF分隔。用一段伪报文来表示就是HTTP/1.1 200 OK Content-Type: text/html X-Powered-By: PHP/7.4.33 - 这里是一个空行\r\n\r\n html.../html问题就在这里HTTP协议规定一个头部字段的结束标志就是\r\n。如果某个头部字段的值里混入了\r\n协议解析器会认为当前头部已经结束随后出现的字符会按照“新头部字段”或“响应体”来解析。所以假如开发者写了header(X-username: . $_GET[name]);当nameadmin%0d%0aSet-Cookie: evil1时实际发出去的响应头会变成HTTP/1.1 200 OK X-username: admin Set-Cookie: evil1攻击者拿到了一次“往响应里追加任意HTTP头”的机会。如果再追加一个空行就能继续控制响应体实现完整的响应拆分。1.2 PHP的header()函数为什么不拦很多人会下意识认为PHP的header()既然是个内置函数总该对非法字符做些限制吧还真没有。PHP手册对header()的说明很简短发送原生HTTP头。它只是把你传入的字符串原样拼到响应头里并不会校验里面是否包含\r或\n。这也意味着只要开发者把用户可控数据直接拼进去就可能有注入点。我见过不少初学者用str_replace把\r\n替换掉然后以为万事大吉。实际上攻击者可以绕过的姿势很多比如直接传URL编码后的%0d%0a、用数组参数让PHP解析出特殊值、或者利用多字节编码的变体。后面我会专门讲这些绕过与排查。1.3 哪些PHP功能容易踩雷Header注入的常见入口主要集中在这么几类场景重定向跳转时拼接URLheader(Location: . $url);文件下载时拼接文件名header(Content-Disposition: attachment; filename . $name);自定义调试头header(X-Debug-Info: . $_SERVER[HTTP_X_FORWARDED_FOR]);登录后拼接用户名header(X-Welcome: . $username);与第三方接口对接时把返回值直接放进响应头。只要输入能最终拼到“HTTP头字段的值”里就有同样的风险。接下来逐个细看。2. 常见入口排查哪些代码看起来安全其实很危险2.1 下载接口里的文件名拼接待处理下载返回文件是Header注入的重灾区。我给客户做渗透测试时十个项目有七八个都存在类似写法$file_name $_GET[filename]; header(Content-Type: application/octet-stream); header(Content-Disposition: attachment; filename . $file_name);这种写法存在两个风险点注入CRLF新增任意响应头如果filename传入../../etc/passwd还可能造成路径穿越。即使用户输入看起来只在浏览器里影响“另存为”的文件名它也是HTTP响应头的一部分。报文传输时不会有任何“帮你截断文件名”的逻辑所有字符都会原样发给客户端。我在实验里传入/download.php?filenametest.pdf%0d%0aSet-Cookie:PHPSESSIDattacker抓包看到的响应是这样的HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Disposition: attachment; filenametest.pdf Set-Cookie: PHPSESSIDattacker面对这种接口你很难要求所有使用者都输入纯文件名所以必须在代码层强制处理。2.2 跳转逻辑里的Location头无法幸免有些逻辑需要根据参数跳转比如$goto $_GET[url]; header(Location: . $goto);攻击者提交/goto.php?urlhttp://evil.com%0d%0aX-Injected:%20yes响应里就会多出X-Injected头。如果再配合%0d%0a%0d%0a攻击者还能在响应体里注入自己的内容把整个页面替换成钓鱼页面。实际上很多框架会对Location做强校验比如检查是否以http://或https://开头。但PHP原生代码、老项目里这种裸拼还是很多。遇到这类场景我建议用白名单协议校验而不是黑名单过滤。2.3 登录态与Cookie操作中的隐藏注入点PHP的setcookie()函数才是容易被忽略的另一个角落。它本质是帮开发者生成Set-Cookie响应头setcookie(user, $_GET[user]);如果$_GET[user]里包含\r\n生成的Cookie头里就可能被塞进新头。PHP 7.x 之后虽然对setcookie增加了一些参数校验但默认情况下仍然允许值里的控制字符。测试过很多版本在PHP 7.4、8.0上依旧可以构造出额外响应头。除此之外还有直接操作$_COOKIE往自定义响应头里回显的情况$token $_COOKIE[token]; header(X-Auth-Token: . $token);Cookie本身就是用户可控的只要有人能自行设置Cookie就等同于直接控制注入内容。放在现代浏览器里虽然部分浏览器会直接拒绝包含CRLF的响应头但在服务端日志、中间缓存、非浏览器客户端里依然能被解析利用。2.4 框架项目不一定就安全不少朋友认为“用框架就不会有这类问题了”这是个误区。Laravel、ThinkPHP等框架在设置响应头时会做一定处理但如果你在控制器里直接调用PHP原生的header()或者使用response()-header($key, $value)而$value是用户输入框架并不能自动帮你清洗所有场景。以Laravel为例header()方法最终会把值交给Symfony的Response对象而Symfony本身对头部字段值有一套过滤逻辑部分非法字符会被剔除。但如果你在中间件里拼了原始字符串或是在模板渲染中用了setHeader依然可能产生问题。更关键的是很多二开项目会混用原生header()和框架方法这种“混搭”最容易出漏洞。所以排查时不要只看框架自带方法还要全局搜索header(调用点逐个人工确认参数来源。3. 注入后能造成什么危害不只是多一行响应头3.1 响应拆分从改头到改页面响应拆分HTTP Response Splitting是Header注入最经典的升级利用方式。攻击者在注入点加入\r\n\r\n后后续内容会被HTTP解析器当作响应体。还是以上面的X-Username为例输入/header.php?nameadmin%0d%0a%0d%0ahtmlscriptalert(document.cookie)/script/html实际响应会被解析成HTTP/1.1 200 OK X-Username: admin htmlscriptalert(document.cookie)/script/html我本地复现时在浏览器里直接看到了注入的HTML代码执行。也就是说注入点从“多了一个响应头”升级成了“直接控制页面内容”。如果站点上有其他用户请求同一响应代理服务器还可能会把这段伪造页面缓存下来让更多用户中招。3.2 会话固定与Cookie篡改注入Set-Cookie是实现会话固定的捷径。攻击者先通过漏洞注入一个自己指定的会话ID例如Set-Cookie: PHPSESSIDattacker_session_id用户浏览器收到这个Cookie后后续请求会带上攻击者指定的会话ID。如果用户正好在登录状态攻击者就能拿着这个会话ID冒充用户。我在实际项目测试中成功复现过这个链路通过文件下载接口注入Cookie然后在另一台浏览器上用同一会话ID就直接进入了受害者后台。整个过程不需要获取用户密码只需要用户点击一次攻击者构造的链接。3.3 缓存污染影响范围从单人扩到全站Header注入更大的杀伤力在于和中间缓存结合。很多站点前端用CDN或反向代理比如Nginx、Squid缓存HTTP响应。如果代理服务器对多个用户返回的响应头不做严格区分攻击者注入的伪造响应就可能被缓存下来。设想这样一个场景一个正常的新闻列表页被CDN缓存了但由于攻击者的请求也返回了同样的URL只是在响应头里多注入了一段恶意HTMLCDN判断URL相同、缓存key相同就把这份恶意页面缓存了。之后所有访问该URL的用户都会拿到被污染的页面。虽然现代缓存系统大多会校验响应头或缓存控制字段但配置不当的站点依然存在这类问题。Header注入不直接产生经济损失却经常成为大规模攻击链的第一环。3.4 绕过安全机制与日志伪造有些团队会在Nginx或WAF层通过响应头做安全标记比如X-Frame-Options: DENY Content-Security-Policy: default-src self攻击者通过Header注入可以先注入一个自己的X-Frame-Options: ALLOWALL让页面可以被加载进恶意iframe之后再做点击劫持。也可能注入假的Content-Security-Policy覆盖原有策略让XSS防护失效。这类利用不直接触发报警但会给后续攻击打开方便之门。我在排查日志时还见过用Header注入往日志里写垃圾数据的情况攻击者注入X-Client-IP:头让运维的日志分析平台无法准确追踪来源。4. 实操复现本地搭建一个可验证的测试环境4.1 用PHP内置服务器5分钟跑起来学习Header注入最好的方式是在本地搭一个最小可复现环境。不用搞Nginx、ApachePHP自带的开发服务器足够。先创建一个测试目录里面放一个header_test.php?php $name $_GET[name] ?? ; header(X-Username: . $name); echo 当前用户: . htmlspecialchars($name);在终端启动php -S 127.0.0.1:8080然后打开另一个终端用curl发一个正常请求curl -v http://127.0.0.1:8080/header_test.php?nameadmin正常返回里只会有一行X-Username: admin。接下来换成注入payloadcurl -v http://127.0.0.1:8080/header_test.php?nameadmin%0d%0aSet-Cookie:%20PHPSESSIDattacker注意-v参数会打印完整请求和响应头。这时你会看到响应里多了一行Set-Cookie: PHPSESSIDattacker为了确认后端服务器没有自动过滤我还在PHP 7.4和PHP 8.0上分别测过结果一致。这说明header()函数从底层就不阻止CRLF。4.2 增加响应体注入的完整payload响应头注入成功后下一步试试响应拆分。把payload改成curl -v http://127.0.0.1:8080/header_test.php?nameadmin%0d%0a%0d%0a%3Chtml%3E%3Cscript%3Ealert(1)%3C/script%3E%3C/html%3E观察返回HTTP报文里会变成HTTP/1.1 200 OK Host: 127.0.0.1:8080 X-Username: admin htmlscriptalert(1)/script/html由于PHP内置服务器默认可能使用Content-Length或分块传输具体报文格式会有差异但“多出的响应体内容被浏览器当作页面内容”这一点是确定的。如果你用浏览器打开这个链接会直接弹出alert(1)。4.3 用Burp Suite抓包确认细节命令行只能看到原始报文如果你想看更细的解析过程建议用Burp Suite抓包。把浏览器代理指向Burp然后用Burp Repeater发送payload。Repeater里可以直接看到每一行响应头的高亮和编号。如果注入成功Set-Cookie会作为独立的头部字段出现。Burp还能帮你测试各种编码变体比如%0d、%0a、\r\n直接输入等。我平时测试时习惯在Repeater里来回切几种编码方式确认后端是否有过滤。需要提醒的是做这类实验请一定在本地或授权测试环境中进行。Header注入虽然看着不起眼但它能直接影响所有协议解析方放到公网上就是高危漏洞。5. 防御措施从源头掐断到多层兜底5.1 编码上的硬规则禁止任何控制字符进头部最稳妥的规则是任何即将写入HTTP头字段的字符串都必须经过一次“控制字符清洗”。我习惯写一个统一函数function safeHeaderValue(string $value): string { // 移除所有控制字符包括 \r \n \0 \t 等 return preg_replace(/[\x00-\x1F\x7F]/, , $value); }然后在所有header()调用前调用它header(X-Username: . safeHeaderValue($name));之所以把\t也过滤掉是因为HTTP头字段值虽然允许Tab但部分代理和服务器对Tab的处理不一致容易引起解析差异增加不可控因素。严格模式下建议只允许可打印ASCII字符。5.2 场景化处理文件下载与跳转的专用写法文件下载是Header注入的高危场景。与其在源头过滤不如干脆不让用户传“完整文件名”。我推荐的写法是$filename basename($_GET[file]); // 先取基名 $filename rawurlencode($filename); // 再URL编码 header(Content-Type: application/octet-stream); header(Content-Disposition: attachment; filename\{$filename}\; filename*UTF-8{$filename});basename()去掉了路径部分rawurlencode()会让特殊字符变成%xx形式CRLF自然无法再作为控制字符出现。filename*是RFC 5987定义的扩展支持非ASCII文件名现代浏览器都能正确识别。跳转场景则用白名单协议校验$allowed_host example.com; $url $_GET[url] ?? ; if (!preg_match(#^https?:// . preg_quote($allowed_host, #) . #i, $url)) { // 非白名单直接跳到默认页 header(Location: https://example.com/); exit; } header(Location: . $url);这里不仅过滤了CRLF还限制了跳转范围杜绝了开放重定向。5.3 框架与组件的规范化处理如果你用Laravel尽量别混用原生header()。可以在控制器里这样做return response() -json([status ok]) -header(X-Username, safeHeaderValue($name));Symfony组件的ResponseHeaderBag本身会对头部值做合法性校验但为了统一规范还是建议在业务层先做好清洗别把安全完全寄托在框架上。ThinkPHP 6.0 也提供了Response对象推荐用return json([status ok])-header([ X-Username safeHeaderValue($name), ]);我见过不少项目在控制器里一边用框架返回、一边又用原生header()加自定义头这种混用会让安全审计变得很困难。统一入口是降低漏报率的第一步。5.4 服务端与代理层兜底即使代码层做了防护还是建议在Web服务器或反向代理层再拦一道。Nginx可以增加响应头过滤规则但配置比较复杂。更实际的做法是Nginx层禁止上游返回包含未编码CRLF的响应头需要借助headers-more-nginx-module等第三方模块Apache则可以通过mod_headers做关键字替换如果有WAF开启响应头注入检测规则。这些属于兜底措施不能替代代码层修复。因为不同服务器版本、模块组合差异很大如果只在服务器层做拦截一旦换端口、换服务就失效了。5.5 定期代码审计与自动化扫描防御要持续做。我在团队里定的规范是所有header()、setcookie()、setrawcookie()调用必须通过代码扫描工具检测参数来源每次发布前用grep全局搜索header(人工确认每个参数是否可控新功能如果不确定某个值是否可控一律先走清洗函数。静态扫描可以靠 PHPStan、psalm 配合自定义规则无法覆盖的地方就用正则搜索关键函数。虽然麻烦但比线上出事故后处理划算太多。6. 常见问题与排查技巧实录6.1 过滤了 \r\n 为什么还是被注入这是我很长一段时间的困惑。一开始我用str_replace([\r, \n], , $input)过滤但测试时依然注入成功。后来排查发现攻击者传的是URL编码后的%0d%0a。PHP在接收GET参数时会自动做一次URL解码也就是说$_GET[name]拿到的已经是被解码后的字符串。此时你杀\r\n是有效果的。但如果没杀干净或者攻击者在中间加一层编码比如UTF-7、Unicode的空格变体就有绕过可能。更稳妥的是直接从协议层面把控制字符全杀掉我用的是preg_replace(/[\x00-\x1F\x7F]/, , $input)。这样不管是\r、\n、\0还是其他不可见字符一并清除。注意if关键字判断条件时有些项目只过滤了精确的\r\n遗漏了单独出现的\r或\n这也是常见的失败原因。6.2 构造了payload浏览器却不弹窗第一次复现响应拆分时我在Chrome里没看到预期弹窗一度以为漏洞不存在。后来发现是浏览器对响应报文容忍度不同Chrome如果检测到响应头里有明显的CRLF注入会直接拒绝解析这个响应甚至显示“服务器错误”。但这不代表漏洞不存在。换成curl看原始报文或者用Python的requests库去请求都会看到被拆分后的完整响应。还有一点要特别注意有些CDN或反向代理会把含有CRLF的响应头拦截掉直接返回502这种情况下浏览器也不会有任何异常。所以测试时不要只依赖浏览器必须抓原始报文。6.3 日志里查不到攻击问题可能出在响应头我在一次应急排查里遇到奇怪现象某用户访问首页偶发页面异常但应用日志里查不到任何报错。最后抓取了原始HTTP响应发现Content-Type被添加了一个额外的; charsetutf-8导致浏览器以错误编码渲染。这个额外值来自一个自定义的调试头调试头从$_SERVER[HTTP_USER_AGENT]里取了部分信息拼接而用户UA中恰好包含了CRLF。因为页面内容本身没变应用日志自然没有任何记录。从那以后我就养成了一个习惯排查看不到问题时把原始请求和响应一起抓下来逐行看头部。6.4 细节补漏几个容易忽略的小点第一PHP的$_SERVER[HTTP_*]变量完全由客户端控制任何拼接进响应头的操作都等于把控制权交给外部输入。我曾经在一个项目里看到别人把HTTP_X_REQUESTED_WITH直接写进X-Requested-With响应头这同样是注入点。第二不要只关注响应头请求头里的Host、Referer也可能被带入错误页的meta http-equivrefresh或日志系统。如果它们参与了页面输出要一并清洗。第三测试时多注意数组参数。比如$_GET[name]传入name[]xxxPHP会把它变成数组直接拼接进header()会导致类型错误或生成奇怪字符串。有些开发者会隐式转换(string) $name在数组转字符串时PHP会抛出异常反而掩盖了注入路径。但如果你用implode或者循环拼接数组元素过滤不严就会绕过单点校验。第四反向代理层面的缓存策略也值得检查。即使应用代码修复了如果CDN节点还缓存着恶意响应影响会持续一段时间。我通常会建议在修复后清除相关URL缓存并给所有敏感响应增加Cache-Control: no-store。最后再分享一点个人经验干安全测试这几年看到太多项目在业务功能上堆得飞快却在响应头这种“小地方”栽了跟头。Header注入最大的特点就是“平时看不见出事才后悔”。它不直接改页面不写数据库但通过它可以伪造会话、污染缓存、覆盖安全策略甚至直接控制响应体内容。我在团队里定了一条规矩代码里任何写响应头的地方一律走统一封装函数参数必须经过safeHeaderValue()清洗。这个函数不复杂但能挡住绝大多数常规绕过。每次上线前还会全局搜索header(和setcookie(把可疑调用点列出来再过一遍参数来源。如果你现在正维护老项目建议立刻搜索这几个关键字header(、setcookie(、setrawcookie(逐一确认有没有用户可控参数直接拼接。如果项目里有文件下载、URL跳转、自定义头回显这类功能更要重点排查。别等到被扫出来漏洞报告才动手那时候可就不是改两行代码那么简单了。