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,判断每个接口的操作属性(增删改查)、服务调用链、数据库与表的调用,对于处理脏数据问题和数据安全问题都有比较好的辅助作用

热门相关:超武穿梭   刺客之王   大神你人设崩了   仗剑高歌   网游之逆天飞扬