PHP怎么防HTTP头注入？换行符过滤与响应头校验-php教程-PHP中文网

http头注入本质是利用\r\n换行截断伪造响应头，php的header()函数不自动过滤控制字符，故所有拼接用户输入的响应头（如location、set-cookie）必须经白名单校验与上下文感知清洗，禁用原始字节注入。

php怎么防http头注入？换行符过滤与响应头校验

HTTP头注入的本质是换行截断

PHP里用header()函数写响应头时，如果参数里混入\r或\n，就会被浏览器解析成两个独立的HTTP头——攻击者借此插入Set-Cookie、Location甚至伪造整个响应体。这不是PHP特有漏洞，而是所有语言共通的协议层风险。

关键点在于：PHP不会自动过滤这些控制字符，header()函数照单全收。所以任何拼接进header()的变量，只要可能含用户输入（比如从$_GET取值生成跳转地址），就必须先清理。

常见错误场景：header('Location: ' . $_GET['url'])，攻击者传url=https://a.com%0D%0ASet-Cookie:admin=1即可劫持后续请求
危险字符不止%0D%0A，原始字节\r\n、\n、\r都要拦截
不能只依赖urlencode()或rawurlencode()，它们只编码URL，不处理换行符本身

用filter_var()做白名单校验比正则更可靠

对要写入响应头的字符串，优先走白名单校验而非黑名单过滤。比如跳转地址，就该限定为合法URL结构；自定义X-User-ID头，就该只允许数字和短横线。

filter_var()内置的FILTER_VALIDATE_URL和FILTER_SANITIZE_URL能覆盖大部分场景，但要注意：

FILTER_SANITIZE_URL会删掉\r\n，但也会删掉合法的@、:等字符，不适合用于完整URL拼接
更稳妥的是组合使用：filter_var($input, FILTER_VALIDATE_URL)先校验，再用str_replace(["\r", "\n"], '', $input)做兜底
若字段只需简单格式（如用户名、ID），直接用filter_var($input, FILTER_SANITIZE_STRING)并配合ctype_alnum()判断更轻量

响应头写入前必须做上下文感知处理

不同响应头对内容要求差异极大：Content-Type要严格匹配MIME类型，Set-Cookie有固定语法，Location必须是绝对URI。不能用同一套逻辑处理所有头。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

实操建议：

Location头：用filter_var($url, FILTER_VALIDATE_URL) + parse_url()检查scheme是否为https或http，拒绝javascript:、data:等伪协议
Set-Cookie头：不要手动拼接，改用setcookie()函数，它内部已做安全处理
自定义头（如X-Trace-ID）：用preg_replace('/[^a-zA-Z0-9\-_\.]/', '', $value)白名单清洗，长度限制在64字符内
永远避免把$_SERVER['HTTP_*']变量原样塞进header()，比如$_SERVER['HTTP_REFERER']可能含恶意换行

Apache/Nginx配置可作为最后一道防线

即使PHP代码漏判，Web服务器层也能拦截明显异常的响应头。但这只是纵深防御的补充，不能替代代码层校验。

Apache示例（.htaccess或虚拟主机配置）：

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
# 拒绝包含\r\n的Set-Cookie头（需mod_headers）
Header edit Set-Cookie ^(.*)$ "$1; HttpOnly; Secure"

Nginx中可用add_header强制覆盖，但无法动态过滤响应头内容。真正有效的服务器级防护是禁用危险模块（如Apache的mod_userdir）和关闭AllowOverride All，防止.htaccess被恶意覆盖。

最易被忽略的一点：开发环境常关掉display_errors，但忘了关expose_php。暴露PHP版本号本身虽不直接导致头注入，却为攻击者选择利用链提供线索——这类细节往往在上线前被跳过。