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