假设这个完成了(1)

---

目录：

---

引子：

在开发过程中，Boss常常跟我提的一句话就是：“假设这个东西完成了”。
一开始，没听懂这句话的意思，只是照着去做，后来慢慢自己体会到这句话的奥妙了。

从几个工具的开发过程来谈谈这句话的奥妙吧~

---

poc扫描器的开发：

需求的产生：

当一些新的危害性很大的漏洞爆发出来后，由于某些原因，公司的web扫描器无法及时的添加扫描规则，也就是说不具备扫描新型高危漏洞的能力。

所以问题就来了，同时也产生了新的需求：要在原有的基础上，写一个能够扫出高危漏洞的poc扫描器。

---

什么是poc扫描器：

科普一下，啥是poc扫描器：

poc : proof of concept翻译过来就是概念验证，就是要找出一个方法去验证某种东西是否存在或者它是真是假。

举个例子，比如说，《木兰诗》中有一句话说到双兔傍地走，安能辨我是雄雌，这个时候，雄雌两兔一起并排着跑，怎能辨别哪个是雄兔，哪个是雌兔呢？如果你能找到一个方法，来检验、分辨出这两只兔子是真是假，那么你的这个方法就是所谓的poc，概念验证了。

延伸到安全这块的意思就是，提供一个方法，去验证某个漏洞是否存在。

一般情况下，一般的思路就是：

• 往一个网站或一个服务器的某个地方、参数发送一个特意构造的数据(抓起一只兔子)
• 从返回包中的数据的一些特征，进行判断(看兔子有木有小jj)

---

poc扫描器的难点1：找兔子

如果你想判断兔子是公是母，那你先要抓到兔子啊，你才好使出你的判断大法：看兔子有木有小jj？！

也就是说，你要找到漏洞环境先，你才好使出你的判断大法：从返回包中看特征。

第一个难点来了，去哪里找兔子呢？

• 稍微缩小目标
  
  • 去动物园找、你可以专门去兔子乐园找
• 再缩小目标：
  
  • 去专卖兔子的宠物店找

同样的，在web安全中，去哪里找漏洞环境呢？

• 真实的公网环境上
  
  • 稍微缩小目标，通过zoomeye,fofa,Shodan来找
• 离线的漏洞环境
  
  • 再缩小目标，github上有几个提供漏洞的docker环境的，美滋滋

---

poc扫描器的难点2：看兔子有木有小jj

如果此时你抓到了兔子了，满心欢喜的想要看兔子有木有小jj，可是并非每只兔子的那个特征都是那么明显的，万一你抓到一只怪物兔子呢。万一是雌雄同体、万一那兔子的小jj长满了毛。。。。真拿不准你能判断出它是公是母，这个时候就考验你的眼力了。

有两种方法：

• 比较明显的话，就直接肉眼判断、再不行就拨开兔子肚子的毛来看
• 不明显的话，就采取旁门左道、比如解剖、拿一只母兔子看那只兔子有没什么反应。。。

同样的，如果你找到了漏洞环境，那么你满心欢喜的想构造数据包，去看特征，由于种种原因，这个时候也未必能看到你想要的特征。

有两种方法：

• 一般情况下，有回显的漏洞特征，比较好判断，用某个特征符去匹配就行
• 如果是无回显的情况下，只能运用旁门左道来间接证明了。dnslog、或者时间上的延迟来判断。

---

poc扫描器的难点3：找到那只真正的兔子

如果只是双兔傍地走的话，这个时候还好，你的眼前只有2只兔子，可是。。。如果是满草原的兔子呢？你该怎么办？更何况当中还要掺杂着别的动物，什么小松鼠、小老鼠、小猫的。。。

有两种方法：

• 1、全部都抓起来。。。这样的好处是不会漏。。但是有点傻
• 2、先给动物分类，然后打上标签、按标签去找到你要的对应的动物

同样的，在真实的网络环境中，你要扫描的资产中含有很多web组件，你要怎么判断你要找出哪个组件来进行漏洞证明呢？

有两种方法：

• 1、暴力的方法：遍历、全部、FullScan

  • 对爬取得到的所有链接、都往对应的位置发送构造好的数据包

• 2、缩小范围、QuickScan

  • 先指纹识别、缩小范围后、再往特定的地方去打数据包

---

实际开发过程中：

由于以上的3个难点：

• 找兔子
• 看兔子有木有小jj
• 找到那只真正的兔子

搞得我在开发这个poc扫描器的时候一头雾水，选了一个poc后，一开始执着于这个poc验证率要准确，要找到对应的漏洞环境验证后、才能用。

那些天，boss反复提了几句话

• 你不要执着于某个poc的验证率，要假设这个poc能用
• 然后要先把整个框架写出来
• 一个事情要先完成个百分之80后，再慢慢去修改细节。而不是一开始就纠结于一些点
• 再这样纠结下去，过了一两个星期后这个事情还是没完成大部分的内容，就会变得棘手了

通俗点的说：

• 你不要执着于一开始抓到一只兔子、就一直反反复复看它有没有小jj
• 你要把整个框架即找兔子、抓兔子、验证兔子的这个流程先搞定
• 不然一两个星期后，你手里还是只有一两只兔子，整件事情就会很棘手了

我当时还是有点执着于那个点：一个准确的Poc才能上架
但是总的开发思路还是按照boss的说法去做的，现在回过头来想，路子还是挺对的，保持着一个比较良好的开发节奏。

当然，我自己也额外加班，把自己执着的点给完善了。

---

总结：

良好的开发节奏：

• 在开发一个比较大的工程、项目的时候，难免会遇到一些棘手的点。
• 这个时候，如果这个棘手的点一时无法解决，那么可以先放一放。

• 一些比较简单的点，花较少的时间就可以做完，这个时候整个项目的进度就会很快。
• 当整个项目的进度到了八九成之后，再回过头来，把难点一个个的逐步击破。

大局观：

在整个项目开发的过程中，boss的整个大局观还是比我强太多了。。

从一个概念、一个需求到的一个工程化的、可用的项目(产品)的整个大局观值得去细细体会和捉摸。

这种大局观应该是经验跟思考堆起来的，目前来说不太懂。。。

---

假设这个完成了：

通常我们有个to do list

一般情况下，都是会顺序的从第一点做到最后一点，如果当中某个点卡住了，我们就会在上面花费很多时间。如果不巧的是难点出在前面几个点，那么我们的整个进度就会停滞不前。

这个时候，我们要提醒自己一句。

• 假设这个完成了

这句话很奇妙，虽然听起来很虚，但是可以使你暂时不拘泥于小结，而是从大局的角度去看待问题，对整个大局观有个比较好的把握，而不是顺序的去逐个解决问题，而是有种倒推的感觉。

• 反过来想

就是从结果往回看，如果要达到这个结果，我们需要做什么，这当中存在着一种必要性的思维，对于解决问题来说是很有益处的。

• 最后再举个例子

比如说我们要搭一条小船，如果在前期搭建过程中，我们被材料这个问题困扰着，犹豫着哪个材料是最好的，而迟迟没有动手开始搭建小船，那很可能数天过去了，我们的小船还没有成型。

如果我们一开始选择跳过一些难点，先选一种较好的材料就开始着手于搭建起整个小船，很可能数天过去了，我们要的小船就基本成型了，基本可以用了。

回过头想，是否选用了最好的材料可能也不是那么重要了。

整个过程是受到多因素影响的，每个因素对于最终结果的影响程度是不一样的。

• 如果从某个点来说，那个点确实很重要
• 但是从面来看，可能当时你执着的那个点变得没有那么重要了。

---

inspire&more:

伴随着近代科学理性的高扬，人类步入了物质财富极大丰富、技术文明高度发达的现代社会，黑暗时代的迷信和蒙昧被远远地抛弃到了历史的废墟中，但是另一种“谬误、无知、盲目、危难”却悄无声息地隐藏在科学理性的暗影中。莫兰指出：它们“产生于我们认识的一种肢解性的组织方式，无能认识和理解现实的复杂性”，这是一种“分离/还原/单方面”的“简单性范式。

— 《复杂性思想导论》埃德加·莫兰