转载

浅谈业务安全通用解决方案的构建

“你们安全不要阻碍业务发展”、“这个安全策略降低用户体验,影响转化率”--这是甲方企业安全部门经常听到合作团队抱怨。但安全从业者加入公司的初衷绝对不是“阻碍业务发展”,那么安全解决方案能否成为“业务促进者”,而非“业务阻碍者”呢?答案是肯定。

在安全产品中,和业务解耦、对客户透明的安全产品,如防火墙、IDS、WAF等就很少遭受到类似的吐槽。

但回归到互联网业务安全场景,业务安全防控常见场景往往如下:

场景一:

安全:”这个安全策略需要你们把用户登录的IP发给我。”

业务开发改造N天上线。

安全:“这里有一部分IP不对啊,是不是取的网关的内网IP。”

业务开发:。。。

场景二:

业务开发:”安全让我们纪录user-agent、浏览记录,现在服务的性能都消耗在打日志上。做这些有业务价值吗?”

安全:。。。

这些场景核心问题都在于业务安全解决方案通常嵌入业务逻辑中。那互联网业务安全有没有如同防火墙一样通用的解决方案呢?要解答这个问题我们先探究业务安全的“通用安全风险”。

0×01 业务安全通用安全风险

要找到业务安全的通用风险,首先得定义什么状态才算业务“安全”。当安全工程师被客户问到“这个产品是否安全?”,他往往会考虑各种安全细节问题,业务类的是否会被撞库、是否存在信息泄漏,系统类的是否有注入、水平权限控制等问题。但这些安全细节问题,往往并非问题“是否安全”的答案。

客户所需要的“安全”是一个平衡状态。没有绝对安全的系统,再健壮的系统也有可能因为安全问题而遭受资损,同时为系统提高安全性也并非零成本。 所以客户需要的“安全”是安全成本和安全资损的平衡。 为一个DMZ区的博客服务器配备一个专属安全工程师保障不被入侵不是客户需要的“安全”。节约安全成本却导致大规模的撞库事件也不是客户希望的“安全”。

回归到业务安全场景,会发现一个共同特征。只有达到 一定规模,批量利用,业务安全漏洞 才会造成业务影响,产生用户无法承受的资损。一次Web攻击可能就写入webshell导致机器沦陷,但有限次的撞库、垃圾注册、垃圾消息、刷单造成的资损是企业可以承受的。而攻击者要达到大规模,批量性的目的,都要通过机器来自动化实现。所以可以得出结论—— 大规模、批量性的机器风险是业务安全领域面临的通用风险

0×02 通用解决方案需求分析

上节已经得出大规模、批量性的机器风险是业务安全领域面临的最大痛点,那么要实现通用的“解决机器风险方案”有哪些需求。针对机器风险业界防御手段已经很成熟--针对人类知识(验证码)、针对人类固有特征(行为识别)、消耗机器成本(POW)等。但业界仍无整合这些防御手段提供通用普适的业务安全 解决方案 ,问题主要有两点——无法做到业务透明和快速部署。

业务透明

现有的人机识别方案,客户需要前端、后端的改造进行接入,甚至于业务需要配合安全方案进行业务逻辑的调整。安全侵入业务主逻辑,有时候安全甚至成为业务的负担。

快速部署

机器风险防御手段过于复杂,无法快速部署,进而导致业务系统无法通过配置简单的实现全站部署防控。而业务系统往往有无数的小流量入口,这些未进行部署的入口往往成为漏洞。

0×03 通用解决方案具体实现

如何实现“业务透明”、“快速部署”的通用机器风险解决方案呢?核心是能够以 中间人的方式介入浏览器和业务服务器 之间,实现如下需求:

1、在页面注入相应的Javascript脚本;

2、 Javascript脚本采集数据并hook用户所有触发提交操作的事件,将数据在用户发起请求时注入请求中;

3、能够代理转发浏览器与业务服务器的请求,并解析请求内容;

现在中间人攻击工具(MITMf)已经相当成熟,而逆向应用中间人攻击工具的思路似乎可以达成这些需求。在业务服务器与浏览器之间部署反向代理服务(通常为WAF),用户在浏览网站时由WAF注入前端需要数据采集的JS,同时JS在前端hook用户的请求事件,用户发起请求时将采集的风险识别数据注入,请求再次到达反向代理时,由反向代理提取相应风险识别数据提交风控大脑进行综合决策判断是阻断用户请求还是发起二次校验挑战。

业务风险防火墙在业务服务器与浏览器之间的交互流程如下图:

浅谈业务安全通用解决方案的构建

关键的业务风险防控采用三层漏斗模型进行层层过滤,达到透明阻断业务风险的目标。这三层漏斗模型分别是:阻断机器从而杜绝攻击者批量攻击的风险,异常流量分析识别部分漏网的机器行为及行为轨迹异常的不良用户,征信模型基于对于用户的信誉评分拒绝不良用户,最终达到将服务推送给目标用户的目的。

浅谈业务安全通用解决方案的构建

阻断机器:

1. 针对人类固有特征进行机器识别,基于JS实现的可信前端采集用户行为数据,通过线上实时模型来发现机器行为进行阻断;

2. 消耗机器攻击成本从而让攻击得不偿失,基于POW(proof of work)原理,通过服务端下发问题消耗前端的计算量。对于有足够空余CPU资源的普通用户少量的计算并不消耗成本,而攻击者需要达到批量攻击的效果则会占用极大的计算资源,让攻击得不偿失。

流量分析:

通过机器学习对网络流量中的异常流量进行识别,从而拦截上一层漏过的行为轨迹异常的不良用户,常见思路如下:

1. 浏览轨迹,比如在互联网金融场景,正常用户会在注册后对比多款理财产品最后进行下单,而“羊毛党”往往在群里得到活动信息就会直奔活动页面薅羊毛;

2. URL聚类,在网络购物场景,正常用户购买某款商品之前一般会在同类目商品中进行选择;

3. 浏览频率,在UGC网站上,用户浏览和评论的一般是有一定时间间隔,频繁秒回的用户极有可能是在发垃圾消息。

征信模型:

伴随互联网诞生有一句经典的论断”在互联网上,没人知道你是一条狗”。然而业务安全场景,识别用户身份、评估用户信誉是业务风控的重要依据。

借鉴现实社会成熟的征信系统,且现在互联网已经是一个成熟的生态闭环。通过设备指纹标示用户,基于用户在互联网的活动记录进行信誉评分,并辅以失信用户名单,从而对bypass前两层的高风险用户进行拦截。

0×04 业务风险防火墙的价值

回归到文章开始的问题,业务安全防控如何成为“业务促进者”,业务风险防火墙能否达成这个目标?答案是肯定的。

业务风险防火墙有两大优势,而这两大优势在保障企业业务安全同时也达到了促进业务发展提速的目标。

第一,业务透明,业务开发资源可以专注的投入在业务代码上,降低企业达成安全需求的成本。

第二,快速部署,业务风险防火墙可以快速进行全站部署,快速实现对网站业务风险的保障。如同安全带的发明保障驾驶员的安全性同时进而让汽车能够更安全的以更高的速度行驶,对全站进行业务风险防控后也可以让企业真正把业务推送给目标用户,从而让企业的业务发展提速。

本文作者:阿里云誉反欺诈,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)

原文  http://www.freebuf.com/articles/neopoints/110681.html
正文到此结束
Loading...