w13scan今年将进行的更新
字数
1266 字
阅读时间
5 分钟
更新日期
3/30/2020
@amcai给我看了一份它的扫描器，完成了很多w13scan想做但没做的事，原来也有人和我一样，在孜孜不倦研究与开源漏洞扫描器，也让我有了动力，开始更新w13scan。立一个flag，我想在护网前将w13scan更新完毕。
w13scan的定义
需要明确一下对w13scan的定义，在我的设想中，w13scan是一款功能齐全的漏洞扫描器，它能运行在主流操作系统上,windows,mac,linux等，它具有足够的通用性，能涵盖大量漏洞检测的范围，检测方式上，它能够从被动扫描到主动扫描，也可以提供api方便其他程序调用，也能很好的和burpsuite配合。
和xray,awvs相比，它能具有下列几个优势
- 免费/开源
安全从业人员可能不会信任任何程序，唯一能让人稍微信任的就是开源代码。
安全是建立在信任之上，信任需要开放和透明。w13scan核心代码完全开源，任何人可以检查其代码的安全性，确保获得最高级别的保护。
w13scan的所有列出的功能不是虚假的，每个漏洞模块都会有专门的测试用例，能依托社区来测试每个功能模块的准确性。
可以方便针对一些棘手且高度专业化的环境，可以按照w13scan开发文档补充其功能，自定义需要的模块。
- 丰富的检查插件
写w13scan的目的之一就是想将自己看到过的漏洞扫描模块集中整理成python文件的形式，可以方便学习，也可以方便以后调用。
看过很多开源的漏洞扫描器，有的是通用型，有的针对单一漏洞，w13scan会不停的向这些开源软件学习，希望整合这些资源成为开源漏洞扫描器中的top1。
要做的
- w13scan github的issue有很多未处理，先将它们处理了，当初设定的github issue提交模式是自动提交，导致很多用户自定义插件的错误也提交了，新版会将这种方式提交改为手动提交
- 对于post,get等分类插件的代码冗余，设想是不区分get类型插件和post类型插件，按照漏洞类别在同一个检测函数中检测get和post参数。
- 参数提取升级，将解析url path中参数，header参数也加入扫描目标中
- fake request,fake response改造，让其适应主动模式
- 设立插件等级概念，等级越高检测一个目标就会发送越多payload，例如等级1 发送0~3,等级2发送4～10，等级3发送10～30，在插件中根据环境情况使用这些等级来使用更多的payload检测。
- 增加反连平台，支持无回显，fastjson，rmi等的漏洞检测。
- 检测插件升级
- 将语义识别概念，参数动态性检测概念等加入到插件规则中。
- 增加网页报告，增加主动调用接口
- 与burp联动
- api文档编写等
学习的
xray是很好的学习对象，先对标xray来升级吧～
一些困难
- 代理服务器
- w13scan第一版本使用了粗糙的代理服务器来完成被动代理模式，但我核心是只想专注于漏洞插件编写这块，粗糙的代理服务器会保留，后面一个重点是会加入burpsuite插件，burpsuite再将数据发送到w13scan。
- 环境复杂
- w13scan使用的python包尽量选择了能支持全平台的，但还是可能会遇到一些环境上的麻烦，有想过用go重写，但无疑会浪费很多时间来学习，所以还是用最熟悉的python来吧，我相信它会和sqlmap一样，只要功能强大的这些客观因素不算什么
- 在批量测试某些漏洞插件的时候，遇到了request的内存泄漏问题，很严重也很无奈。。所以在批量测试的时候可能会用一些复杂的并发模型来规避这种问题
- 对比
- 虽然和市面上先进的扫描器对比我很荣幸，但w13scan只是个人兴趣的产物，一些无意义的对比只会打击开发者的信心，让开发者怀疑付出的意义是什么，如果想鼓励开发者，可以小额打赏，或者提交一个pull request，这会让开发者高兴需求