从攻击看防御——前端视野下的web安全思考

2022-06-29 17:12:52 浏览数 (1)

作者:徐嘉伟--腾讯高级前端工程师

@IMWeb前端社区

各端安全之争

受开发职能划分的影响,很多人也会下意识地把web安全划分为前端安全和后端安全。更有甚者,甚至会延伸出探讨前端安全与后端安全哪个重要之类的争论。或许作为前端的你,曾经也会听到类似前端安全无意义论的声音,理由大概有:①前端代码开源暴露于浏览器,不安全;②前端影响面局限于单用户浏览器,不重要;林林总总。

但争论并没有意义,重要的是静下来思考。

重新思考

本人近期对自身业务进行了一遍web安全梳理,对web安全有了一定的思考。因自身岗位视野的限制,在对web安全的思考上,难免会有一定的局限性,故题目加上了“前端视野下”这样的修饰词,希望我的思考能给大家带来收获。

web安全,个人认为更多的是一个体系性的东西,目的是为了保护web系统的安全。它既需要单端防御(前端或后端),同时又需要前后端相互配合防御。

个人定义的web安全

那究竟什么是web安全呢?web安全,通俗说就是对攻击进行防范。两个核心名词:攻击、防范。

攻击是攻击者做的,防范则是web平台提供方要完成的行为。所以,我们不妨换个思路——从攻击来看防御。

从攻击看防御

1、攻击的目的

坏人要攻击你,总有他的原因,有的为了盗取你的密码,有的为了查看你的隐私,林林总总。总结起来,个人认为其实可以归纳为两类:

①窃取用户信息

       获取用户登录态、获取帐号密码、获取用户私密信息等等;信息获取后就可以做更多事了,如冒用用户身份、盗取帐号资产、售卖用户隐私等。

②导致产品无法正常使用

       频繁调用服务器接口以搞垮服务器,同类产品的竞争,难免会存在此类目的的攻击。相信红包大战下,除了表面的一片繁华外,也会暗藏着对手对我们的攻击吧。

正因要达到以上目的,才会产生具体的攻击行为。而有攻击行为,当然也会有与之对应的攻击对象,所以思考攻击行为前,我们不妨先看下web的攻击对象。

2、攻击对象&攻击武器

攻击行为必然地会对应到具体的攻击对象上,而web攻击的攻击对象自然就是web体系内的东西了。个人认为攻击对象有三大块:浏览器、传输通道、服务器,这也是web体系的核心内容。

上图中绿色箭头代表的是数据的流向。在web体系中,数据是前端与后端通信的唯一标识,但同时也是攻击者攻击的有利武器。

说到这里,是不是对攻击的本质很明朗了呢。

3、攻击的本质

web攻击,本质上是攻击者通过一系列攻击方式,利用数据流对攻击对象(浏览器、传输通道、服务器)进行攻击,只要其中一个攻击对象被成功攻破,便能达成攻击目的。

我们web安全要做的防御,实质上是针对每种攻击手段,判断其要攻击的对象,并对攻击对象实施保护。

让我们从攻击对象看攻击方式,并针对具体攻击方式思考防御方式吧。

4、从攻击的具体对象,看防御方式

①攻击传输通道

web中的传输通道有两种:

       狭义上来看,是连接浏览器和服务器的网络通道,数据从浏览器端发出,通过网络通道,到达服务器,服务器再把数据结果通过网络通道返回到浏览器。

       广义上来看,还包括网站的传播,比如把网址地址通过微信或手Q分享、QQ消息或邮件或博客或论坛传播等等。

对传输通道的攻击,两种类型通道的攻击手段类似,有两种:数据窃取、数据篡改,对应的防御方法是数据加密、参数签名。

1、数据加密:

         因前端代码开源于浏览器,一般会采用非对称加密算法,后台把公钥和有时效性的随机数传给前端,前端通过非对称加密算法(如:rsa算法)将原数据加密后再发送给后台,后台再根据私钥进行解密,获得原数据。这样即使数据到达传输通道被人截取了,对方没有私钥,其截取到的数据也是没有意义的。

         上述防御方案可以看出,数据加密的防御手段需要前端和后台配合完成,而不仅仅只需某一端防御。

2、数据签名:

         对于微信分享之类的传播通道,页面的url在传播过程中很容易被篡改,如对url参数进行篡改。为了防御该类攻击,往往需要对url参数进行签名,并在url上带上签名参数。这样,如果在传输过程中url参数被篡改,因最终签名串验证不一致,后台会进行拦截,防止该类攻击。(也因前端代码开源于浏览器,签名方法一般由后台或本地控件(程序/原生app)提供,前端直接调用来签名。)

         上述方案可见,数据签名的防御手段依然是需要前端和后台配合的,仅靠其中一端依然不可行。

②攻击浏览器

浏览器,是前端代码的运行平台。该类攻击是数据抵达浏览器后进行的攻击。主要攻击方式有两种:利用浏览器特性攻击、利用前端逻辑漏洞攻击。

1、利用浏览器特性攻击:

         以XSS攻击为例,XSS攻击实际上利用的是浏览器HTML的解析特性。HTML内容其实本身就是一串字符串。浏览器在解析HTML这些字符串的时候,当解析到具体的HTML语法标签,就会按照特定语法特性去解析而非当做字符串解析。XSS攻击利用的正是这点特性,当页面上有渲染非可控数据时(如用户自己输入的数据),若数据为html代码,浏览器不加防御的话,数据就会被浏览器当作代码渲染执行,比如若数据为“<script src=“/*攻击者脚本地址*/></script>”,就会去加载一个攻击者的恶意脚本,而当这个数据能被很多人的页面看见时(如文章、昵称、评论等等),攻击者就能在很多人的页面上为所欲为了(执行恶意脚本)。

         为了防御XSS攻击,需要页面自身进行防御,页面需对非可控数据在渲染前进行过滤处理,过滤方法如下:

可见,对于利用浏览器特性进行的攻击,一般直接由前端保护即可,后台的保护更多的只能是提高攻击门槛而已。(既即使后台做了过滤,前端还是需要再做一次的,因为攻击对象是浏览器侧的,而数据来源不仅仅来源于后台。该攻击的本质在前端)

 2、利用前端逻辑漏洞攻击:

         以URL攻击为例。该类攻击利用的是页面跳转逻辑漏洞。(常见于登录超时后,用户重新登录跳回到登录前的页面)如下例子代码所示,页面跳转地址依赖于url上非可控参数target,页面执行完一定操作后(如登录),会跳转到target参数值的地址:https://testhost.com/target.shtml。

          而如果前端没有对该非可控参数(target)实施防御措施(域名白名单过滤等),这个时候很容易被攻击者利用这一逻辑,把目标地址配成自己钓鱼网站。

         为了防御URL攻击,需前端对非可控参数(target)增加一层域名白名单过滤判断,如:

可见,对于利用前端逻辑漏洞攻击,仍需由前端自身进行保护。

③攻击服务器

          服务器,是后台代码的运行平台。该类攻击是数据对服务器进行的攻击。攻击方式与攻击浏览器的方式是类似的,也可分为两种:利用服务器特性攻击、利用服务器逻辑漏洞攻击。

  1、利用服务器特性攻击:

 以SQL攻击为例。该攻击其实跟前端的XSS攻击是同理的,只不过现在要攻击的对象是后台数据库,所以攻击手段需要针对SQL的特性进行,即发送SQL语法的攻击性语句,如果后台没有实施防御措施,数据就会被当做SQL指令来执行而非普通字符串。防御措施就是对传入数据进行过滤。

         又以文件上传攻击为例,也是同理的,只不过攻击对象是后台的服务器。攻击者把攻击性的可执行文件上传到服务器后台(比如若后台语言采用的是php,上传一php的恶意脚本到服务器),一旦后台没有防范,脚本运行,服务器就会被攻破。防御措施是对上传的文件进行格式判断、隔离存储等等。

         可见,与前端同类的这一攻击,对于利用服务器特性进行的攻击,一般需由后台直接保护,前端的保护(前端过滤)更多的只能是提高攻击门槛。(因为攻击对象是服务器侧的,而前端是可以被绕过的)

2、利用后台逻辑漏洞攻击:

         后台逻辑有很多种,这里以信任逻辑为例。个人把信任逻辑大致分为以下三种:

a、权限区分

即有无做好角色权限控制。以红包为例,要限制只能当前红包发的群里面的人有权限领取,非群内人员无法领取。而如果没有做区分限制的话,一旦被检查到有角色权限控制不严谨的漏洞,就会被利用上这个“官方的”可越权通道进行越权操作(领取无权限红包)。

该逻辑漏洞的攻击需要后台进行防范,做好严谨的权限区分。

b、恶意用户识别

即有无做好恶意用户监控,识别恶意用户并做出防御措施。以恶意攻击为例,如果攻击者频繁调用某接口想要拖垮服务器时,服务器要能快速识别,并做出防御策略(如调用频率超过一定次数时增加图片验证码校验或拒绝访问等)。如果没有相关防御措施,服务器就会因为这一个接口的频繁访问而拖垮,导致产品无法使用。

该逻辑漏洞的攻击也是需要后台进行防范的。

c、伪装用户识别

即能否正确的识别当前用户就是该用户,而非别人。伪装用户的行为因涉及到用户侧,所以与前面的攻击方式不同,该类攻击一般利用的是浏览器的特性,而攻击对象却是服务器(后台识别用户的逻辑不严谨)。

这里以CSRF攻击为例。

CSRF攻击利用的是浏览器cookies的同源策略,cookies在浏览器上是以域名区分存储的,但同时又共享于所有的标签页。当用户登录了目标网站(cookies中含有登录态),中途如果又被引诱进入了钓鱼网站,这时钓鱼网站就伪装成用户给目标网站发请求了(因会带上cookies,cookies上带有登录态)。

因这一特性的存在,后台识别用户的逻辑不能仅靠自身写入cookies中的登录态,还应借助前端额外的一些参数进行校验。

CSRF的防御措施也是利用的浏览器特性:即cookies只能被同域名页面获取。前端需在每个请求均带上一个cookies中获取的token传参,后台收到的每个请求都会校验该token比对下。目前一般的做法是前端获取cookies中的登录态skey并做下简单的加密后传给后台,后台进行判断处理。

可见,对于仅仅利用服务器逻辑漏洞进行的攻击,仅需后台进行防范即可。而如果还利用了浏览器特性进行的攻击,此时还需要前端和后台同时配合防御的。

结语

最后,感谢各位的耐心阅读。

做个简单的总结。其实通过上面的思考分析,可以发现web其实是一个端对端的体系。攻击是针对某一端或者端与端之间的通道进行的。如果攻击的对象是通道,此时往往需要两端协助进行防御;如果攻击对象与攻击利用的漏洞同在某一端,则往往只需该端自身进行防御即可;如果攻击对象和攻击利用的漏洞不在同一端,此时往往需要两端协助防御。

扫码下方二维码,

随时关注更多前端干货文章!

微信:IMWebTech

0 人点赞