防渗透源码

去年秋天，防渗一个做安全审计的透源朋友给我看了段代码。两百来行，防渗塞在一个老旧PHP项目里，透源表面看是防渗处理图片上传的常规逻辑。他让我找找问题在哪。透源我扫了两遍，防渗没看出异常——过滤函数写得挺规范，透源白名单后缀、防渗MIME校验、透源文件重命名，防渗该有的透源都有。他说，防渗你把第47行到第63行单独摘出来跑一下。透源

那段代码做的防渗事很简单：读取上传文件的头部字节，判断是不是合法图片。问题出在判断逻辑上——它用的是exif_imagetype()，但后面跟了个or die()。正常情况没问题。可如果攻击者构造一个文件，头部是合法JPEG标记，后面拼接PHP代码，这个函数会返回真，die()不触发，文件照常写入。更关键的是，写入路径用的是move_uploaded_file()的原始文件名，只做了str_replace过滤../。绕过方法？用....//就行，替换一次后变成../，经典的递归替换漏洞。

这就是防渗透源码的典型困境。你以为自己在防守，其实只是在给攻击者画地图。每一行过滤代码都在告诉对方：我防的是这个，你试试别的。

我后来自己搭了个靶场，专门收集这类“看起来安全”的代码片段。有个Java项目让我印象很深。它用PreparedStatement防SQL注入，参数化查询写得无可挑剔。但登录逻辑里有个“记住我”功能，token生成用的是MD5(username + timestamp)。时间戳精确到秒，用户名已知，攻击者只要在合理时间窗口内爆破就行。更离谱的是，token验证时用了equals()而不是equalsIgnoreCase()，但生成时用的是小写——这种不一致本身不致命，可它暴露了开发者的思维盲区：他以为自己在防A，实际上B才是入口。

防渗透源码的核心矛盾在于：防御者要堵住所有洞，攻击者只需要找到一个。这导致很多安全代码写得像强迫症——层层包裹，处处校验，结果反而制造了新的攻击面。我见过一个文件包含漏洞的修复方案，开发者把include的路径做了realpath()检查，确保在指定目录内。但他忘了realpath()在文件不存在时返回false，而false经过字符串拼接后变成了空字符串，最终include('')触发了include_path里的默认路径。一个检查，变成了另一个漏洞的跳板。

真正有效的防渗透源码往往很“笨”。比如处理文件上传，别去猜攻击者会怎么绕过你的黑名单，直接白名单加随机文件名加非Web目录存储。三步，没有花哨的正则，没有递归替换，没有exif_imagetype。简单到你觉得“这能行吗”，但它就是能行。因为攻击者面对的不是你的过滤逻辑，而是一个他无法预测的文件名和一个他访问不到的目录。

我那个安全审计朋友后来跟我说了句话，我一直记着。他说，看防渗透源码，别看他防了什么，看他没防什么。没防的地方，才是他真正信任的边界。而边界之外，全是攻击者的 playground。

上周我又翻到那个PHP项目的后续版本。第47行到第63行被重写了，换成了finfo_file()加随机重命名加.htaccess拒绝执行。看起来无懈可击。但我注意到，文件上传后的缩略图生成模块，依然在用原始文件名去拼exec()命令。防渗透源码的战争，从来不会结束。你修好一个洞，总有人在另一个地方，挖出新的。