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

@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其实是一个端对端的体系。***是针对某一端或者端与端之间的通道进行的。如果***的对象是通道，此时往往需要两端协助进行防御；如果***对象与***利用的漏洞同在某一端，则往往只需该端自身进行防御即可；如果***对象和***利用的漏洞不在同一端，此时往往需要两端协助防御。

标签：web,浏览器,前端,防御,后台,服务器,视野
来源： https://blog.51cto.com/15080021/2586437