前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从攻击看防御——前端视野下的web安全思考

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

作者头像
用户1097444
发布2022-06-29 17:12:52
3330
发布2022-06-29 17:12:52
举报
文章被收录于专栏:腾讯IMWeb前端团队

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

@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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-04-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯IMWeb前端团队 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 各端安全之争
  • 重新思考
  • 个人定义的web安全
  • 从攻击看防御
    • 1、攻击的目的
      • 2、攻击对象&攻击武器
        • 3、攻击的本质
          • 4、从攻击的具体对象,看防御方式
          • 结语
          相关产品与服务
          验证码
          腾讯云新一代行为验证码(Captcha),基于十道安全栅栏, 为网页、App、小程序开发者打造立体、全面的人机验证。最大程度保护注册登录、活动秒杀、点赞发帖、数据保护等各大场景下业务安全的同时,提供更精细化的用户体验。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档