DAST 黑盒漏洞扫描器第 3 部分：无害

一个。在nginx层的公司级监控中，发送的请求超过了某个接口设置的QPS阈值

湾。在web框架的监控中，请求QPS超过阈值

C。在业务自己设置的监控中，请求超过阈值

d。业务接口本身没有超过阈值，但是后端的二次调用或者多次调用（RPC或者其他http服务）超过阈值

如何处理？

2.1.2 聚合控制qps的关键点

QPS控制需要确定两点：

1 聚合方式：如何将不同的URL聚合成一个key

为什么需要聚合？我们要控制的是对业务接口的请求量，而不是我们看到的 URL 的访问量。

a 相同的路径，但参数不同，大多数情况下处理的是相同的接口和相同的功能；

b 而且现在动态参数很常见，比如百度贴吧帖子

最后十位数字不在参数中，而是在路径中。后端将该路径的值作为变量读取。不管数字如何变化，都是由同一个接口处理的。

c 甚至子域也可能对应同一个接口

大多数情况下，不同的城市，如北京bj、上海sh、广州gz等，都对应同一个美食列表页面服务

如果未聚合，则为每个看起来完全相同的 url 设置 1 的最低 qps。同时扫描post时，即使每个url每秒只发送一个请求，但在同一时间段内url数量较多时，也会进行此处理。接口发起的流量也会变得非常大。尤其是在业务高峰期（早上8:00到晚上10:00有大量业务请求），接口压力相当大。基于流量镜像方式，接收到的URL也很多。进行另一次扫描很容易破坏业务。的悲伤。

因此，聚合理论上是在自己的范围内将具有不同表面的 URL 捆绑在一起。当然，界面越接近，越准确。

2 QPS值：对应key可以使用多少QPS，每秒可以发送多少请求

QPS 值取决于接口的容量和设置的告警阈值。

值设置高，容易炸毁服务接口；如果该值设置得低，扫描速度会变慢，并且在流量大的情况下可能消耗不完。

最合适的上限值是正常业务条件下请求量的平均值或上限。

有些服务会根据每分钟的请求总数设置告警，每分钟100-1000，对应QPS为1-17。对于流量较小的接口，QPS 为 1 就足以报警。

2.1.3 不同的实现

域名聚合

同一域名或子域名的请求不应超过 N(5-10).

一刀切的方法具有成本低、效果好等优点。

缺点是绝对相等，无论流量大小都使用相同的QPS。当流量较大时，可能无法完成扫描。

与任务绑定适用于扫描任务多但每个任务流量不大的情况，例如多用户多任务。

b 集群聚合

对于每一个url，根据nginx解析结果，获取该url最终所属的业务集群。

结合内部监控数据，获取各集群的实时访问量，计算各集群的访问峰值；

用峰值减去实时流量（前n分钟）得到备用可用流量

缺点：

1 依赖于内部基础设施的资源

2 对于同一集群下的接口，可用的访问权限是基于整个集群的。比如A可以用300、B可以用300、C可以用300，整个集群可以用900，但是A自己只能承受500。这样一来，就会有一个QPS 倾斜，所有访问都会命中 A，这会炸毁 A。

c 去重聚合

镜像模式下，基本上会有一套去重流程和流量清洗服务，去重时会记录每个key的实时访问量。

使用去重key作为聚合值，QPS计算方法和之前一样。计算每个key的峰值，然后减去前n分钟的qps（在可控范围内尽量少），得到这个可用的key在分钟内。

结合路径相似度和页面相似度的去重，去重key贴近界面，效果理想。

2.1.4 QPS 限制方法

如果插件的最小任务单元已经拆分到请求级别，则可以将请求任务放入队列，根据可用量读取并运行请求任务。

但是插件需要上下文关联的情况很多，比如第一次请求获取登录凭证token，第二次请求使用token进行后端RCE等。

此时扫描规则发送请求时，该请求没有可用的QPS，如何限制

方法一

直接休眠，等待它可用再发送，但会导致任务挂起，占用节点。有多少资源并不重要。

方法二

超过限制后返回重试队列

但下一次扫描不是从头开始，而是从上次停止的地方继续扫描

没有断点重新扫描，一些插件将无法被完全扫描。比如有些规则在扫描的时候没有限制，每秒10个请求，不能成功；并且QPS控制服务的边缘属于引擎，应该不影响规则本身的检测。影响

记录每个扫描任务的每个请求哈希（url++），对插件进行分类（有无上下文键）；

对于没有上下文的规则，直接跳过下一个任务已经请求过的hash；对于有上下文的规则，存储每个hash的返回，重试时已经请求的hash直接从前一个返回中读取。

2.2 业务错误码错误

业务线将监控服务的稳定性和可用性。最简单的是错误代码的百分比，例如每分钟 404/504。

可用性将直接影响业务 KPI 和指标。

在这里，您应该收集每一个反馈，与内部监控平台沟通讨论需求，并在识别到内部扫描时删除这部分请求；如果是单个业务自己收集错误，就只能自己解决这些问题。

这里注意保持业务溯源简单，扫描的时候自定义/ua/ IP等，否则要等很久才能追根溯源才发现是内部扫描，业务会比较多生气的。

2.3 脏数据

脏数据是一个无法避免的问题。

镜像模式下，只过滤掉post和post，只扫描get，可能还是有脏数据问题。

理论上get应该是用来查询和操作的，但是业务要做增删改操作也是可以理解的。

get里面可能有用户凭证，业务并没有把token放到里面，而是放到get参数里面，一般会保存在里面。这种情况下，用get参数值扫描就相当于用用户的身份扫描。如果有信息的增删改操作，用户的数据就会变脏。

再比如业务写接口，登录接口获取手机验证码，?phone=xxx&type=1，获取此流量进行扫描，扫描类型时，重复发送验证码给用户，用户认为该帐户正在被涂黑。

或者，没有增删改查等，只是简单的查询，却因为频繁访问用户信息，被逆转，用户被封禁。

方法 1 清洁和标记

在2.1中，我提到了接口；在我们拥有所有接口数据后，借用其他安全产品（SAST/IAST）的能力，给接口打上标签，判断是增删改查；添加、删除、修改操作只需小心跳过，避免大部分脏数据业务影响。然后设置参数名黑名单，过滤掉具有明显用户特征的参数名取值，如phone/token/tele。

这种方式比较安全，覆盖范围取决于SAST/IAST的能力，但是也会导致这些接口的漏报

方法二爬虫

通过爬虫，第一篇1.2.4，使用自己的测试账号抓到的流量，通常脏数据问题会比较少，因为这些请求是普通用户可以访问的，是从外部发送的来源。扫描仪将收集它。

用户可以访问的界面会造成脏数据，也就是说外部用户也可以造成脏数据，尤其是外部白帽/黑客也会扫描。不是不扫描就不存在问题，只是没有暴露出来。

方法三阴影环境

直接复制已有的DB环境和服务环境，将扫描请求/压测请求通过nginx层转发到影子环境。风险极低，但代价巨大（cost*2）.

或者干脆复制DB环境，在数据库连接函数中做一个hook，把扫描请求的数据库链接改成影子库。但是操作起来很麻烦，开发和维护成本高，而且多层调用最终到达DB，很难判断是否与原始请求关联扫描。

并且除了常规的数据库mysql/mongo/redis/MQ/kafka等，还有其他数据库甚至本地日志等，有的操作转了其他的操作没有转，业务数据层不一致，并且只能通过反馈来维持。，比较麻烦，不推荐。

方法四测试环境

第一篇1.2.6，扫描测试环境。

开放扫描作为业务线的一项功能。当业务可控时，无需过滤各种参数即可进行扫描。QA 在了解风险时进行扫描。

甚至可以进行流量标记，允许业务选择是否扫描涉及到增删改查的接口。

PS：

在一些收购业务中，当系统被扫除时，就会出现问题。没有统一的测试环境，也没有统一的在线获取接口标记代码的流程。它非常脆弱，未经授权的访问无处不在。在这种情况下，什么也做不了。

2.4 扫描时间段

有些业务允许扫描，但希望扫描时间在半夜，因为半夜业务流量低，出现脏数据或QPS等问题，影响比一天中的高峰时段要小，营业“开门”时也有一定程度的“开门”。缓冲时间。

2.5 限制带宽

虽然可以进行过滤，但会造成成本问题，不像静态文件会影响扫描性能。

扫描时，可能会遇到下载文件的界面。一次请求后，接口会将几十或上百兆的文件内容返回给客户端。QPS一上来，带宽就起飞了。在私有云场景中，可以通过云服务购买带宽包，可以收取分级费用，也可以收取使用费。一旦超过，可能会多花几百万，足以造成严重事故。

所以在过滤流量的时候也要过滤掉-,-type属于下载类型。

0X03 主机端口扫描无害3.1 内网HTTP服务错误