DAST 黑盒漏洞扫描器 第一篇：流量
扫描器已经接触了三年，目前比较成熟，在这个方向里，遇到过很多问题，各种方案或多或少接触过。大多数安全产品都可以用流量+规则+引擎+处置来抽象框架，DAST也是这样。而功能，用目的划分，个人拙见主要5个：流量全、规则全、引擎高性能高可用、扫描无害化、运营高效化。这个系列主要是对应功能的描述。
DAST流量主要以web应用(WEB流量以及对应API)和主机服务(HOST流量与域名流量)为主
1 WEB流量
web流量，即有哪些web漏洞
1.1 字段
域名、路径、get参数、post参数、headers；
返回请求的header和body
1.2 来源
1.2.1 线上环境-流量镜像
交换机处通过网卡采集流量，把由外部访问的流量收集并转发。
可参考 https://help.aliyun.com/document_detail/207513.htm
对应的流量类型还有由内到外的访问，合并为南北向流量。
由内到外的流量通常用于IDS 入侵检测系统，检测对外访问是否有木马特征(心跳回连、DGA域名、发起IP较少等)。
东西向流量，即内网server-server流量，通常用于检测内网横向渗透的行为。
流量镜像的特点是全，访问的http流量都可以抓取，缺点也挺明显
- 脏数据
由于抓取的都是访问的流量，那么就可能会带来脏数据。
比如，首页登录处获取收集验证码，用户A点击一次获取验证码后，断断续续收到十几条验证码，感觉很莫名其妙，怀疑是网站泄露了手机号。代码编写的在开发角度也挺合理，手机号作为GET参数传入后端，没有频率限制，没有token，收到请求就发送，当天用完即止。
比如，作为开发，我用户凭证的token不想放在cookie里，而是作为get参数。用户新增了一个收获地址，一天后发现地址列表里多了一百多条看不懂的地址，大为惶恐怀疑账号被黑了。
这是有增删改的场景。
单纯的查询也不是就没有风险，比如，用户访问帖子、商品、文章等列表，扫描的时候触发业务自己的风控，导致接口反爬机制对该用户做了处置(封IP/验证登录等)。 - 数据量过大
互联网公司的每日访问量一般超过百亿，数据量背后需要一套聚合与去重的服务 - 缺乏https
网卡抓取的流量镜像一般是在请求解析前，所以https的流量还没解析。目前https的比例越来越大，简单的流量镜像会导致这一块的安全检测都漏掉
1.2.2 线上环境-nginx流量
为解决https流量，可抓取nginx日志，解析后获取流量，成本较低但不好控制 覆盖率有限(看运维这块记录的内容)
1.2.3 线上环境-WAF流量
WAF流量与镜像流量相似，都是全面的流量，与镜像流量不同的是，WAF通常是在nginx层后，可获取https流量
1.2.4 线上/测试环境-爬虫
采用爬虫模拟用户操作抓取流量
好处：
采用自身测试账号抓取的流量，通常脏数据问题会比较少，因为这些请求都是正常用户可以访问到发出的，也是外部扫描器会收集到的。有问题的情况一般是业务存在漏洞、比如越权、注入、存储XSS等。
缺点：
- 覆盖率问题
采用基于无头浏览器的爬虫爬取的流量，可以实现js的解析，解决前后端分离（vue.js）等问题，能实现覆盖率90%。但是移动端APP流量的爬取还是个难题 - 研发成本
爬虫可能遇到访问的时候中断、卡住的问题，各种各样的JS功能并不可预料，遇到异常情况需要适配优化，这方面需要持续投入 - 运营成本：cookie问题
如果作为一个服务提供给业务使用，并没有这个问题。而想要全面hold住，业务线很多，每个业务线下的业务可能需要的账号权限都不一样。即使有统一的passport，同一个账号，这个业务有没有开VIP，那个业务有没有认证(用户的实名认证、微信绑定，商家的营业执照认证等等)，场景繁多，意味着需要一套持续维护的登录服务，账号、密码、自动登录的页面和验证码破解。召回时不断添加，实在繁琐，运营成本极大 - 资源成本
采用无头浏览器模拟浏览器操作的pc web爬虫、以及app爬虫等，都极大的占用资源
1.2.5 测试环境-浏览器插件
采用浏览器插件的形式，将访问中的流量抓取下来，通过redis或者接口的方式发送给后端，再到引擎进行扫描，最后将结果返回平台；插件访问接口做漏洞提醒。
单纯的作为一个能力，提供给QA使用，QA控制流量开关
优点：简单、可控
缺点：安全培训的推广，直接影响了整体使用率。在业务线不负责安全漏洞成本的情况下，推广难度较大。
1.2.6 测试环境-统一抓取
使用HIDS/IAST实现流量抓取，结合CI/CD平台，在CD平台上提供扫描能力，由QA自行开启。
QA比较反感无感知的漏洞扫描，而且还用了QA的cookie，所以一定要站在QA角度 考虑QA的感受。
QA并不想在测试的时候有较多的其他请求，所以不能实时同步扫描。QA也不想自己测完了，还要等待很长时间的安全扫描，所以不能做定时收集与扫描。最好的方式还是提供给QA能够自己控制的安全测试能力，在测试结束后，可将这次测试的流量投到DAST中。
扫描的时间窗口也要做限制，2-3分钟内适宜，这就要求web扫描插件的时间需要控制在合适的范围内，比如sqlmap做接口扫描方式可能不可行。超过时间窗口的只能丢弃或者以线上安全漏洞工单形式发送。
卡点：卡点功能最好也是由业务线可控，可以以报表的形式描述开启率
如果能够分辨增删改流量，也可以将这部分流量是否扫描的控制交给业务
优点：作为一种能力提供给业务使用，QA可自行控制风险
缺点：理论上是可全覆盖的，初始阶段因抓取服务的部署率和业务线合作程度，覆盖率会比较低，但这两方面都可以通过技术手段以及运营推广手段(漏洞成本转移/安全培训)提升
2 HOST流量
1.1 字段
IP、端口、端口指纹、IP所属集群(漏洞找人)、IP所属业务线等
1.2 来源
内部平台：IT资产信息、运维CMDB、HIDS等
IP来源较为广泛，有的时候较为复杂的内网，运维也无法清楚有多少IP，存在很多找不到人的IP
黑盒扫描：采用masscan+nmap的方式，做全网段存活主机发现、主机端口服务探测
内部获取的资产信息以及黑盒角度收集的资产信息，是互补的两个途径。
通过两种途径结合起来的资产，往往会比内部其他平台更全一些。
1.3 资产指纹
而HOST资产，最好还有打标流程，收集每个端口的指纹、http响应，将nmap的nmap-service-probes做成可配置的指纹检测规则，扫描时判断具体端口服务。各字段匹配出多特征、多特征组合成打标规则。
一方面是0day出现时判断影响范围，另一方面是快速进行应急响应、漏洞扫描。
3 域名流量
域名是对外开放的一个口子，像一些框架漏洞、CORS，往往是整个域名都存在的、对域名下的每一条URL检测效果都一样。
这时候需要域名资产。
检测时结合公网资产，对域名的端口进行扫描，在应急上ROI也比较高(一般0day爆发、外部漏洞扫描时，先用漏洞对企业所有域名扫一遍)
4 API
API是web流量的演化，如线上流量的去重规则到了较为成熟的时候，离线URL流量接近于企业的API。
对API作打标，结合SAST/IAST，判断每个接口的操作属性(增删改查)、服务调用链、数据库与表的调用，对于处理脏数据问题和数据安全问题都有比较好的辅助作用