近日心血来潮筹备谈谈 “缝隙检测的那些事儿”。此刻有一个现象就是一旦有风险较高的缝隙的验证 PoC 或者操作 EXP 被发布出来，就会有一大群饥渴难忍的帽子们去刷洞，对付一个路人甲的我来说，看得有点眼红。XD

刷洞归刷洞，蛋还是要扯的。缝隙从披露到研究员分析验证，再到 PoC 编写，进而到大规模扫描检测，在这环环相扣的缝隙应急生命周期中，我认为最关键的部分应该算是 PoC编写 和 缝隙检测 这两个部分了：

PoC编写 - 复现缝隙环境，将缝隙复现流程代码化的过程

缝隙检测 - 使用编写好的 PoC 去验证测试方针是否存在着缝隙，需要注意的是在这个过程（或者说是在编写 PoC 的时候）需要做到安适、有效和无害，尽可能或者制止扫描过程对方针主机孕育产生不成恢复的影响

首先来说说 PoC 编写 。编写 PoC 在我看来是安适研究员或者缝隙分析者日常最根本的事情，编写者把缝隙验证分析的过程通过代码描述下来，按照差别类型的缝隙编写相应的 PoC。按照常年编写 PoC 堆集下来的经验，小我私家认为在编写 PoC 时应遵循几个准侧，如下：

随机性

确定性

通用型

可能你会感受我太学术了？那么我就一点一点地把他们讲清楚。

PoC 编写准则 & 示例
i. 随机性

PoC 中所涉及的关键变量或数据应该具有随机性，切勿使用固定的变量值生成 Payload，能够随机生成的尽量随机生成（如：上传文件的文件名，webshell 暗码，Alert 的字符串，MD5 值），下面来看几个例子（我可真没打告白，例子多半使用的 pocsuite PoC 框架）：

上图所示的代码是 WordPress 中某个主题导致的任意文件上传缝隙的验证代码关键部分，可以看到上面使用了 kstest.php 作为每一次测试使用的上传文件名，很明显这里是用的固定的文件名， 违背 了上面所提到的随机性准侧。这里再多烦琐一句，我并没有说在 PoC 中使用固定的变量或者数据有什么不同错误，而是感受将能够随机的数据随机化能够降低在扫描检测的过程所承当的一些危害（具体有什么危害请自行脑补了）。

按照随机性准侧可改削代码如下：

变动后上传文件的文件名每次都为随机生成的 6 位字符，小我私家认为在必然水平上降低了扫描检测交互数据被追踪的可能性。

ii. 确定性

PoC 中能通过测试返回的内容找到独一确定的标识来说明该缝隙是否存在，并且这个标识需要有针对性，切勿使用过于模糊的条件去判断（如：HTTP 请求返回状态，固定的页面可控内容）。同样的，下面通过实例来说明一下：

上图所示的代码是某 Web 应用一个 UNION 型 SQL 注入的缝隙验证代码，代码中直接通过拼接 -1' union select 1,md5(1) -- 来进行注入，因该缝隙有数据回显，所以如果测试注入告成页面上会打印出 md5(1) 的值 c4ca4238a0b923820dcc509a6f75849b ，显然的这个 PoC 看起来并没有什么问题，但是结合准则第一条随机性，我感受这里应该使用 md5(rand_num) 作为标识确定更好，因为随机化后，准确率更高：

这里也不是坑你们，万一某个站点不存在缝隙，但页面中就是有个 c4ca4238a0b923820dcc509a6f75849b ，你们感受呢？

讲到这里，再说说一个 Python requests 库使用者可能会忽视的一个问题。有时候，我们在获取到一个请求返回东西时，会像如下代码那样做一个前置判断：

可能有人会说了，Python 中条件判断非空即为真，但是这里真的是这么措置惩罚惩罚的么？并不是，颠末实战遇到的坑和后来测试发明， Response 东西的条件判断是通过 HTTP 返回状态码来进行判断的，当状态码范畴在 [400, 600] 之间时，条件判断会返回False 。（不信的本身测试咯）

我为什么要提一下这个点呢，那是因为有时候我们测试缝隙或者将 Payload 打过去时，方针可能会因为后端措置惩罚惩罚逻辑堕落而返回 500 ，但是这个时候其实页面中已经有缝隙存在的标识呈现，如果这之前你用适才说的要领提前对 Response 东西进行了一个条件判断，那么这一次就会导致漏报。So，你们知道该怎么做了吧？

iii. 通用性