文章总结： 本文剖析主流黑盒扫描器检测服务端注入漏洞的三大盲点：冷门技术覆盖不足导致SSTI等漏洞漏报、变体与过滤器组合使百万payload方案失效、隐藏注入点难以定位。作者基于经典手测思路演化出扫描逻辑，成功挖掘研究级漏洞，建议结合人工审计思路开发更智能的扫描工具。 综合评分： 82 文章分类： 渗透测试,漏洞分析,红队,WEB安全

花大价钱买的扫描器，扫不出我随手挖的 RCE

原创

升斗安全XiuXiu 升斗安全XiuXiu

升斗安全

2026年9月16日 07:58 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

【引言】本篇是”反斜杠驱动的扫描”系列第一篇。先不谈怎么造工具，而是先聊一个让人丧气但必须认的事实：主流黑盒扫描器在找服务端注入漏洞时，有三个几乎治不好的”死穴”。看懂这三个盲点，你就明白为什么很多洞只能靠人肉挖出来——以及为什么有些洞连人都差点漏掉。

说实话，干渗透这行越久，越觉得那些卖扫描器的厂商宣传册和现实是两码事。

圈子里有个心照不宣的共识：自动化扫描器嘛，也就是扫扫”低垂的果实”——那些路边随便谁都能一眼看出来的低级漏洞。这话大体没错。跟人肉审计比，扫描器本质就是一份”预设 payload 清单 + 特征签名匹配”的机器活儿，思路和杀毒软件差不多。它缺的是适应力。所以哪怕是最顶配的商用扫描器，碰到人类审计员一眼能看穿的漏洞，它也经常睁眼瞎。

当然，这评价对某些场景不太公平。比如客户端问题，XSS 那一类，现在的扫描器已经相当能打，甚至能靠静态加动态分析揪出 DOM 型 XSS。但服务端呢？SQL 注入、代码注入、命令注入——这些藏在水面下的东西，黑盒扫描器天生就看不见服务端发生了什么，所以检测起来格外费劲。

这正是今天想聊的东西。接下来我会先扒开扫描器的三个核心盲点，然后告诉你：当我把一种从经典手测技术演化出来的思路做成开源扫描器后，它居然能挖到研究级别的漏洞，甚至理论上能在 SSTI（服务端模板注入）这个类目被公开之前就把它揪出来。

盲点一：冷门技术，扫描器的”灯下黑”

先说个道理：在安全圈，”靠冷门活得安全”这一招，对扫描器同样管用。

拿 SSTI 举个例。这是当应用把用户输入不安全地拼进模板引擎时会出的洞，视引擎不同，往往能直接拿代码执行、控下整台服务器。扫描器要发现它，得给每种模板引擎硬编码专属 payload。你用的是 FreeMarker、Jinja 这种大路货，没问题；可问题是——下面这一长串模板引擎，你的扫描器认识几个？

Amber、Velocity、ASP.NET、Blade、CheetahTemplate、ColdFusion、Dust.js、FreeMarker、Genshi、Go templates、Haml、Handlebars、Jinja、Liquid、Mako、Mustache、Pebble、Razor、Smarty、Twig、Thymeleaf……（这还只是维基百科收录的那一部分，没列全的能再数出几十种）

我数过，光是维基百科收录的就有上百种。而前阵子在 PayPal 挖到的那个 RCE，根因就是 Dust.js 的 SSTI——Dust.js 是 LinkedIn 出的引擎，上面那张清单里根本没有它。

冷门漏洞的应用照样天天被扫。早期做 SSTI 研究时，那会儿这问题还没公开，有个客户跟我说 Burp 在他们站上报了个”XSS 误报”。我去一看，所谓的误报底下，藏着一个严重得多的 SSTI。

说白了：凡是踩在”冷门技术长尾”上的应用，扫描器的命中率会断崖式下跌。

更坑的是，扫描器被迫对后端技术栈做假设。一个服务端组件的变动，可能顺带把”八竿子打不着”的漏洞检测也搞崩。比如应用在 SELinux 下跑，那 LFI、XXE 这类通常靠读 /etc/passwd 来验证的洞，可能直接测不出来——因为 SELinux 根本不让读。

盲点二：变体与过滤器，百万 payload 的死局

再看一个大家都熟悉的语言里、大家都熟悉的漏洞：PHP 双引号字符串里的盲注代码执行。扫描器发个 sleep 延迟就能探到：

”.sleep(10).”

挺顺。可如果应用刚好把括号过滤了呢？照样能打，但扫描器给出假阴性：

”.sleep 10.”

要是前面还挡了道 WAF，专门盯”sleep”这个词？又假阴性。这时候如果应用会做输入规范化，我们拿西里尔字母”е”顶替”e”，指望它被归一化成拉丁 e：

”.sl%D0%B5ep(10).”

如果应用把双引号也过滤了？还是假阴性，可应用照样一打就穿：

{${sleep(10)}}

这几个花样，我本人在测试里亲历过俩，第三个是看别人 writeup 学来的。

扫描器的设计，天生就容易被”意外的过滤器 + 非标准变体”撂倒。它当然也能发上面这些变体 payload，可那只是单个漏洞无数变体里的冰山一角。以现在的网速，想把每个漏洞的每种变体都覆盖，根本不现实——这就是”百万 payload 问题”。扫描器只能发”尽力而为”的 payload，意味着哪怕只是用双引号代替单引号包 SQL 语句这种基本操作，都足以让它整个瞎掉。

盲点三：被埋起来的洞，扫描器根本不知道往哪打

给你一段 eBay 某个旧 PHP 注入端点的请求，你猜扫描器该往哪塞 payload？

GET /search/?q=david HTTP/1.1     Host: sea.ebay.com.sg   User-Agent: Mozilla/5.0 etc Firefox/49.0     Accept: text/htmlAccept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://sea.ebay.com.sg/Cookie: session=pZGFjciI6IjAkLCJlx2V4cCI6MTA4 Connection: close

最显眼的注入点是 q 参数——不行。Referer、User-Agent、session cookie？都不行。老手可能会试 Origin、X-Forwarded-For、X-Forwarded-Host 这些”不存在的头”——也不行。

扫描器走到这儿，已经灌了一堆 payload 啥也没中。而 David Vieira-Kurz 发现，真正能打的是再传一个 q 参数，在服务端凑出个恶意数组：

GET /search/?q=david&q[1]=sec{${phpinfo()}}

他为啥会试这招？因为 q 参数会触发一个带拼写检查器的搜索，还会过滤某些关键词——这本身就是个线索：服务端在搞怪。

你看，这又是一个”扫描器除非对每个端点无限发 payload，否则根本测不到”的洞。这例子算极端，但像 Accept-Language 这种”平时没啥用”的头里藏的洞，同样很容易被漏。

如果这篇戳到了你（或者你也曾被扫描器的假阴性坑过），点个赞让我知道你来过。顺手关注一下，中篇我直接把手测思路拆成可落地的扫描逻辑，别错过。觉得有用就转发给带你入坑的那个人，说不定他正卡在某个”明明有洞却扫不出来”的项目上。

小编最近用AI搭建了个学习英语单词的小工具–词塔，可学习9100+的单词/有常用句子跟读/微语法等功能，均可免费使用。正好想用碎片时间巩固英语的，可以试用一下。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：升斗安全 升斗安全XiuXiu 升斗安全XiuXiu《花大价钱买的扫描器，扫不出我随手挖的 RCE》