从***看防护——前端视野下的web安全思考

做者：徐嘉伟--腾讯高级前端工程师

@IMWeb前端社区

各端安全之争

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

但争论并无意义，重要的是静下来思考。

从新思考

本人近期对自身业务进行了一遍web安全梳理，对web安全有了必定的思考。因自身岗位视野的限制，在对web安全的思考上，不免会有必定的局限性，故题目加上了“前端视野下”这样的修饰词，但愿个人思考能给你们带来收获。

web安全，我的认为更多的是一个体系性的东西，目的是为了保护web系统的安全。它既须要单端防护（前端或后端），同时又须要先后端相互配合防护。

我的定义的web安全

那究竟什么是web安全呢？web安全，通俗说就是对***进行防范。两个核心名词：***、防范。

***是***者作的，防范则是web平台提供方要完成的行为。因此，咱们不妨换个思路——从***来看防护。

从***看防护

一、***的目的

坏人要***你，总有他的缘由，有的为了盗取你的密码，有的为了查看你的隐私，林林总总。总结起来，我的认为其实能够概括为两类：

①窃取用户信息

       获取用户登陆态、获取账号密码、获取用户私密信息等等；信息获取后就能够作更多事了，如冒用用户身份、盗取账号资产、售卖用户隐私等。

②致使产品没法正常使用

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

正因要达到以上目的，才会产生具体的***行为。而有***行为，固然也会有与之对应的***对象，因此思考***行为前，咱们不妨先看下web的***对象。

二、***对象&***武器

***行为必然地会对应到具体的***对象上，而web***的***对象天然就是web体系内的东西了。我的认为***对象有三大块：浏览器、传输通道、服务器，这也是web体系的核心内容。

上图中绿色箭头表明的是数据的流向。在web体系中，数据是前端与后端通讯的惟一标识，但同时也是***者***的有利武器。

说到这里，是否是对***的本质很明朗了呢。

三、***的本质

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

咱们web安全要作的防护，实质上是针对每种***手段，判断其要***的对象，并对***对象实施保护。

让咱们从***对象看***方式，并针对具体***方式思考防护方式吧。

四、从***的具体对象，看防护方式

①***传输通道

web中的传输通道有两种：

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

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

对传输通道的***，两种类型通道的***手段相似，有两种：数据窃取、数据篡改，对应的防护方法是数据加密、参数签名。

         一、数据加密：

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

         上述防护方案能够看出，数据加密的防护手段须要前端和后台配合完成，而不只仅只需某一端防护。

         二、数据签名：

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

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

②***浏览器

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

         一、利用浏览器特性***：

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

         为了防护XSS***，须要页面自身进行防护，页面需对非可控数据在渲染前进行过滤处理，过滤方法以下：

         可见，对于利用浏览器特性进行的***，通常直接由前端保护便可，后台的保护更多的只能是提升***门槛而已。（既即便后台作了过滤，前端仍是须要再作一次的，由于***对象是浏览器侧的，而数据来源不只仅来源于后台。该***的本质在前端）

         二、利用前端逻辑漏洞***：

         以URL***为例。该类***利用的是页面跳转逻辑漏洞。（常见于登陆超时后，用户从新登陆跳回到登陆前的页面）以下例子代码所示，页面跳转地址依赖于url上非可控参数target，页面执行完必定操做后（如登陆），会跳转到target参数值的地址：https://testhost.com/target.shtml。

          而若是前端没有对该非可控参数（target）实施防护措施（域名白名单过滤等），这个时候很容易被***者利用这一逻辑，把目标地址配成本身钓鱼网站。

         为了防护URL***，需前端对非可控参数（target）增长一层域名白名单过滤判断，如：

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

③***服务器

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

          一、利用服务器特性***：

         以SQL***为例。该***其实跟前端的XSS***是同理的，只不过如今要***的对象是后台数据库，因此***手段须要针对SQL的特性进行，即发送SQL语法的***性语句，若是后台没有实施防护措施，数据就会被当作SQL指令来执行而非普通字符串。防护措施就是对传入数据进行过滤。

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

         可见，与前端同类的这一***，对于利用服务器特性进行的***，通常需由后台直接保护，前端的保护（前端过滤）更多的只能是提升***门槛。（由于***对象是服务器侧的，而前端是能够被绕过的）

          二、利用后台逻辑漏洞***：

         后台逻辑有不少种，这里以信任逻辑为例。我的把信任逻辑大体分为如下三种：

         a、权限区分

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

         该逻辑漏洞的***须要后台进行防范，作好严谨的权限区分。

         b、恶意用户识别

         即有无作好恶意用户监控，识别恶意用户并作出防护措施。以恶意***为例，若是***者频繁调用某接口想要拖垮服务器时，服务器要能快速识别，并作出防护策略（如调用频率超过必定次数时增长图片验证码校验或拒绝访问等）。若是没有相关防护措施，服务器就会由于这一个接口的频繁访问而拖垮，致使产品没法使用。

         该逻辑漏洞的***也是须要后台进行防范的。

         c、假装用户识别

         即可否正确的识别当前用户就是该用户，而非别人。假装用户的行为因涉及到用户侧，因此与前面的***方式不一样，该类***通常利用的是浏览器的特性，而***对象倒是服务器(后台识别用户的逻辑不严谨）。

         这里以CSRF***为例。

         CSRF***利用的是浏览器cookies的同源策略，cookies在浏览器上是以域名区分存储的，但同时又共享于全部的标签页。当用户登陆了目标网站（cookies中含有登陆态），中途若是又被引诱进入了钓鱼网站，这时钓鱼网站就假装成用户给目标网站发请求了（因会带上cookies，cookies上带有登陆态）。

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

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

         可见，对于仅仅利用服务器逻辑漏洞进行的***，仅需后台进行防范便可。而若是还利用了浏览器特性进行的***，此时还须要前端和后台同时配合防护的。

结语

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

作个简单的总结。其实经过上面的思考分析，能够发现web实际上是一个端对端的体系。***是针对某一端或者端与端之间的通道进行的。若是***的对象是通道，此时每每须要两端协助进行防护；若是***对象与***利用的漏洞同在某一端，则每每只需该端自身进行防护便可；若是***对象和***利用的漏洞不在同一端，此时每每须要两端协助防护。