鹅厂原创 | 从攻击看防御——前端视野下的web安全思考

文/garyjwxu 

腾讯CDG事业群——前端开发高级工程师

0各端安全之争

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

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

1重新思考

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

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

2个人定义的web安全

那究竟什么是web安全呢？web安全，通俗说就是对攻击进行防范。两个核心名词：攻击、防范。攻击是攻击者做的，防范则是web平台提供方要完成的行为。所以，我们不妨换个思路——从攻击来看防御。

3从攻击看防御

3.1 攻击的目的

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

窃取用户信息

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

导致产品无法正常使用

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

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

3.2 攻击对象&攻击武器

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

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

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

3.3 攻击的本质

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

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

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

3.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攻击，需要页面自身进行防御，页面需对非可控数据在渲染前进行过滤处理，过滤方法如下：

/** * 过滤XSS的非法字符 * @method filterScript * @param {String} str 需要进行过滤的字符串 * @return {String} [过滤后的字符串] */function filterScript(str) {    var text = document.createTextNode(str),       parser = document.createElement("div"),       value = "";   parser.appendChild(text);   value = parser.innerHTML;   text = null;   parser = null;    return value;}

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

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

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

https://testhost.com?target=https%3A%2F%2Ftesthost.com%2Ftarget.shtml

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

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

/** * 跳转域名是否在白名单内 * 白名单：testhost.com */function isInWriteList() {    var target = getParameter('target');    return /^http[s]?:\/\/([^\/\?\&\#\\\%\*]+\.)?(testhost)\.(com)/i.test(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并做下简单的加密后传给后台，后台进行判断处理。

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

4小结

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

做个简单的总结。其实通过上面的思考分析，可以发现web其实是一个端对端的体系。攻击是针对某一端或者端与端之间的通道进行的。

• 如果攻击的对象是通道，此时往往需要两端协助进行防御；

• 如果攻击对象与攻击利用的漏洞同在某一端，则往往只需该端自身进行防御即可；

• 如果攻击对象和攻击利用的漏洞不在同一端，此时往往需要两端协助防御。

腾讯 2017 IMWebConf前端大会门票免费送

点击下方礼包，打开文章链接

在评论区留下足迹，回答的点赞数越高，惊喜越多哦！

点我点我