截断上传漏洞，下列说白了就是关于攻击者在文件名里塞进一个特殊字符，让服务器以为文件在某个位置就结束了。截断最常见的上传元凶是空字节（%00）和换行符（%0a）。很多文章把这事儿说得神乎其神，漏洞但有个流传甚广的描述说法其实站不住脚——“只要过滤了空字节，就能彻底防住截断上传”。不正这话错得离谱。下列

空字节截断确实老派，关于原理也简单：在C语言里字符串遇到\0就停，截断早期PHP底层处理文件名时也吃这套。上传你上传一个“shell.php%00.jpg”，漏洞服务器可能只认到“shell.php”就完了。描述但这是不正2008年前后的老黄历了。现在的下列PHP早就修复了这个问题，文件系统函数不再把空字节当终结符。你要是现在还只测%00，八成是白费劲。

真正要命的是换行符截断。攻击者把文件名写成“shell.php%0a.jpg”，某些配置不当的服务器或者中间件，在处理multipart/form-data解析时，会把换行符当作头字段的结束标志。这样一来，文件名被硬生生截断成“shell.php”，后面的“.jpg”被丢进下一个字段里。这招到现在还能在某些老旧系统上奏效，尤其是那些自己拼HTTP报文、没走标准库的代码。

还有个更隐蔽的误区——“截断只发生在文件名末尾”。错。截断可以发生在路径的任何位置。比如你把文件上传到“/uploads/头像_%00.php.jpg”，有些系统在处理路径时，可能把“%00”后面的部分全砍了，最后文件落在“/uploads/头像_”这个目录下。攻击者甚至可以构造路径穿越加截断的组合拳，比如“../../tmp/shell.php%00.jpg”，直接绕过目录限制。

更离谱的是，有些防御方以为“替换/删除%00和%0a就安全了”。但编码绕过来得防。攻击者可以用URL编码、双重编码、Unicode编码来绕过简单的黑名单过滤。比如把%00写成%2500，如果服务器先解码一次再检查，就漏过去了。还有些系统只检查文件名后缀，不检查整个路径字符串，那攻击者把截断符放在目录段里，照样能玩出花。

我见过一个真实案例。某内网系统的文件上传功能，开发者自信满满地过滤了空字节和换行符，还加了后缀白名单。结果攻击者上传的文件名是“report.php%0a.jpg”，后端确实把%0a过滤了，变成了“report.php.jpg”，后缀白名单检查通过。但问题出在存储环节——系统把文件名拼进SQL查询时，用了老旧的mysql_real_escape_string，这函数对换行符处理有缺陷。最终文件存成了“report.php”，直接解析执行。你说讽刺不讽刺，过滤器反而帮攻击者把文件名“净化”成了可执行的PHP。

所以，别迷信单一过滤手段。截断上传的核心问题在于不同组件对特殊字符的解释不一致——Web服务器、应用框架、文件系统、数据库，各自对字符串的切割规则可能完全不同。防御的正确姿势是：用白名单校验文件名后缀，而不是黑名单；对文件名做规范化处理，把编码全部解码后再验证；存储时重命名文件，比如用随机字符串加白名单后缀，彻底切断用户对文件名的控制。

最后说句实在话，如果你还在用“过滤%00和%0a”这种思路写防护代码，那你的系统在2024年就跟裸奔差不多。攻击者早就不玩这么直球的把戏了，他们更爱组合拳——截断加上传路径覆盖、加上传文件内容注入。别把截断当独立漏洞看，它只是整个攻击链里的一环。真正的安全，是让用户输入永远无法直接决定存储路径和文件名。