关于poc脚本的一些问题

什么是 PoC

PoC(全称: Proof of Concept), 中文译作概念验证。在安全界，你可以理解成为漏洞验证程序(本教程中，如无特别说明，默认代表漏洞验证程序)，当然你要强行说我说的不对，我肯定支持你，反正我没打算反驳你。和一些应用程序相比，PoC 是一段不完整的程序，仅仅是为了证明提出者的观点的一段代码。因为是一些代码片段，所以到现在都没看到有一本书来讲怎么编写 PoC 的，因为这些东西对于会写代码的人来说，他们会很惊讶分分钟就会了的事为什么还要出本书。

什么是 Exp

Exp(全称: Exploit),中文叫漏洞利用程序。名字上说的已经很清楚了，简单讲，就是一段可以发挥漏洞价值的程序，这话感觉和没说一样。想象一下这样的场景，目标存在一个 SQL 注入漏洞，然后被你知道了，然后你编写了一个程序，通过这个 SQL 注入漏洞，拿到了目标的权限，那么这个程序就是所谓的 Exp 了，当然，如果你没有使用这个漏洞，它就这么放着，那么这个漏洞，对你来说可以认为是没有价值的。

关于 PoC/Exp 的几个误区

1. 写 PoC 要会 Python.

   这句话，毒害了很多人。PoC 的存在，只有一个目的：证明漏洞存在。而关于 PoC 的形式，或者说代码实现方式，你想用什么方式，就用什么方式。我们推荐 Python, 只是说安全界用 Python 的人居多，你写的东西能被更多人看懂，还有 Python 这门语言的灵活，类库强大等特性，给编写的人提供了很大便利。

   你可以这么理解啊，你要找工作了，你爸妈都推荐你去考公务员，你能说要工作就只能考公务员这种话吗？

2. PoC 就是 Exp.

   这话也不知道是谁第一个说的。其实严格来讲，PoC 和 Exp 是两个东西，你要强行说两个是一个，那你当我没说好了。在我看来，PoC 就是用来证明漏洞存在的，而 Exp 是用来利用这个漏洞的，在很多情况下，我们知道了漏洞存在，却不知道具体怎么利用，编写一个 PoC 非常简单，而编写一个 Exp 是相当有挑战性的。

   PoC 和 Exp 的区别就有点像你发现了家门口的超市的锁有问题，你给人家证明锁有问题和通过锁有问题这个现象偷到超市的钱 这是两码事。

什么是漏洞靶场

漏洞靶场(Vulnerability Firing Range), 就是跑着有漏洞的程序的测试机器。一般用虚拟机来实现，当然现在也有用 Docker 来实现的，反正就是给你一个已经复现了漏洞的环境让你测试漏洞的东西。

我们在学习 PoC 编写的时候，推荐自己搭建靶场来测试，不推荐直接使用互联网上跑着业务的机器，因为现实环境安全配置情况往往要比靶场复杂的多，不利于新手学习，这些都不是重点，重点是万一你不小心把人家机器搞坏了，你说这锅谁来背？你背的起吗？

PoC 编写流程

这里我们不讨论未公开的漏洞，对于一个已经公开的漏洞，PoC 的编写流程是这样的:

1. 根据漏洞详情，寻找受影响版本程序。

   如果是一些 CMS, 可以去 对应的官网下载历史版本程序,有些漏洞作者不会提具体版本号，那你就要根据漏洞作者提交的时间来判断了。当然除了官方网站之外，还可以去 github 上寻找源码，这些个官网都喜欢把历史版本的程序删除掉，善用 github 上的 tag, branch, release 功能，上面有你要的所有版本。

2. 搭建对应漏洞靶场

   这里其实没什么好说的，下载了人家的源码之后，在你的虚拟机里面配置好环境就行了，还能顺便学一下运维的一些皮毛知识。

3. 手动复现漏洞

   根据漏洞详情，手动将整个流程走一遍，熟悉下复现条件，比如使用 GET 还是 POST 请求，需不需要登陆，返回的页面会是什么样子的，我提交不同的参数，会不会出现其它结果，如果漏洞不存在的话，会出现什么样的结果......

   磨刀不误砍柴功，熟悉了这些之后，后面编码实现简直就是分分钟的事，因为一开始我们就说过了，PoC 就是一小段代码。

4. 写代码

   手动复现了一次漏洞之后，分析漏洞证明步骤，根据自己的实际测试情况一步一步写代码，用我的话来说，写代码，其实就是用程序模拟人工操作的每一个步骤，如果你上一步认真做了，这一步只是经验问题，本教程将在后面丰富你在这方面的阅历。

5. 测试 PoC

   其它测试和编码基本都是在同时进行的，为什么要单独提出来讲呢，我们在写 PoC 的时候，除了在存在漏洞的靶机上测试我们的代码，还要在不存在漏洞的站点测试，一般为说，一个优秀的 PoC 在后期测试的时候要求对 10000 个目标测试，误报不能超过 10 个。

PoC 与 PoC 框架

PoC 框架就是一个批量管理，调度 PoC 的程序。因为是框架，要批量调度，那就要求 PoC 在编写的时候要遵守一些规范，这些规范常见的有:

1. 入口规范

   考虑到批量使用 PoC 的调度情况，统一入口框架调用该 PoC 的时候会非常之方便。这个就需要根据具体的框架的调度要求来看了，都有文档的，看一下就会了。

2. API 规范

   API 是该框架对一些基础类库的封装，比如说框架提供了一些网络请求工具。这些封装有什么好处呢？我还是举例子来说明，比如某次扫描，调用了 1000 个 PoC 去扫描目标主机了，假设这个扫描任务中有一部分是需要登录的，而有一些的作者在编写的时候忘记在 PoC 中接收用户自定义的 Cookie 了，那么此时就会因为接收不到 Cookie 而导致请求不成功。那么在使用了框架的情况下，即使在忘记了添加这些字段的情况下，框架也会自动将 Cookie 添加进请求中，为 PoC 开发者提供了极大的便利。