XSS漏洞分析：Content-Disposition头注入导致的反射型XSS

该PHP脚本未对用户可控的token参数做任何过滤或编码，直接拼入Content-Disposition响应头中，可被利用构造恶意文件名实现HTTP头注入，进而触发浏览器解析上下文中的XSS。

这个PHP脚本的问题非常典型——直接把用户传入的token参数拼到了Content-Disposition响应头里，没做任何过滤或编码。结果就是，攻击者可以构造一个恶意文件名，利用HTTP头注入触发浏览器解析上下文中的XSS。这可不是传统HTML上下文里的反射型XSS，而是由HTTP头注入引发的XSS，隐蔽性更强。

问题代码长这样：

$input = $_GET['token'];
$input = str_replace(array("\r\n", "\n"), '', $input); // 仅过滤换行和空字节，防护严重不足
header("Content-Disposition: attachment; filename='$input'");

注意看，代码虽然干掉了换行符和空字节，但回车符、单引号、双引号、分号这些关键字符一个都没防。攻击者可以通过注入CRLF字符实现响应头分裂（CRLF Injection），进而注入任意HTTP头，比如Content-Type、X-XSS-Protection，甚至直接操控后续响应体的内容。

更隐蔽也更容易被忽视的利用路径是：利用浏览器对Content-Disposition中畸形filename值的不一致解析。举个例子，当请求如下：

GET /test/2.php?token='">

服务器返回的响应头会变成：

Content-Disposition: attachment; filename=''">'

服务端虽然声明了attachment，但如果用户手动取消下载，或者浏览器因为MIME类型推测失败（特别是响应没有明确Content-Type: application/octet-stream时），就可能选择直接渲染响应体。这时候，就会被当作HTML执行——这正是Security StackExchange上讨论的Content-Disposition XSS场景的核心风险。

✅ 正确的修复思路：三重防御，缺一不可

• 输入验证：用白名单限制token只能包含字母、数字和下划线，长度不超过64位；
• 输出编码：对filename值使用rawurlencode()（符合RFC 5987标准），或者用addcslashes($input, '"\')加双引号包裹；
• 强制安全响应头：添加Content-Type: application/octet-stream和X-Content-Type-Options: nosniff，杜绝浏览器自作主张地渲染。

加固后的代码示例：

⚠️ 关键提醒：光靠过滤换行符远远不够，依赖客户端行为（比如“用户是否点击保存”）的防御根本不可靠。所有用户输入只要进入HTTP头，就必须严格转义或编码——这是底线。