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服务错误

© 版权声明
THE END
喜欢就支持一下吧
点赞162 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片