在红包活动中如何保障账户的安全

我们经常在做一些福利活动来拉动用户的活跃度，提升APP的拉新和拉活。不过总会有些人在寻找我们活动中的漏洞，以此牟利。那么我们是如何预防这些别有用心的人的恶意攻击呢？这里我们就来聊聊是如何防范的。

首先我们复原下我们活动的玩法： 用户A从客户端内分享自己的专属链接到朋友圈，或者分享到其他地方，分享链接里带有当前用户A的标识、头像、昵称等信息，他的好友B访问这个分享链接时，会读取URL中的参数，然后填充到页面中；用户B点击分享页面中的按钮时，也会将分享者A的标识带入到客户端内，则用户A邀请B成功！用户A和用户B均可获得现金奖励，现金可以进行提现。

首先我们应该知道前端中的攻击都有哪些方式，然后才能针对项目特点进行防范。

1. XSS攻击

百科中这样写道：

XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。其实在web前端方面，可以简单的理解为一种javascript代码注入。

就是说XSS利用的是用户对指定网站的信任，访问了被注入的恶意代码，造成XSS攻击。

在我们整个活动中，用户可能会修改URL参数的地方有2个：

1. 用户A分享出来他的专属分享链接后，在微信、QQ等地方传播时，用户A可以修改他自己的分享链接参数后，再让别人访问；

2. 用户B点击分享链接中的按钮跳转到客户端前，修改URL中的参数，即可修改传递到端内的参数；

在这2种情况里，URL的参数主要有3种：

• sopenid: 用来让其他用户重新带入到客户端内，分享页里不做处理；

• nickname: 展示分享者的用户名，这里作为纯文本处理；

• avatar: 展示分享者的头像，这里对其进行字符串转义；

1.1 节点内容字符串的处理

nickname是要直接填充到页面中的，如果没有过滤，就直接对其进行html字符填充，就会造成程序的混乱，或者被填充恶意的链接，用户可能会无意中跳转到第三方的链接中。比如恶意者在url中使用了一段这样的代码：

COPYHTML
http://news.qq.com?nickname=<script>while(1){alert('hello world')}</script>

那么用户打开这个链接时，就会无限弹窗；

如果恶意者在url中使用了这样的代码：

COPYHTML
http://news.qq.com?nickname=<a style="position:fixed; z-index:999; width: 100%; height: 100%; top:0; left:0;" href="http://www.baidu.com"></a>

用户可能就会不小心跳转到第三方的页面；

因此这里，要么把参数作为纯文本处理，要么对参数里的字符进行转义后再填充：

COPYJAVASCRIPT
var escapeHtml = function(str) {
    return str.replace(/</g,'&lt;').replace(/>/g,'&gt;');
}

1.2 节点属性的处理

我们也会获取URL参数里的avatar作为用户的头像，若用户使用了这样的代码：

COPYHTML
http://news.qq.com?avatar=1"%20onerror="alert(%hello world%27)

那么填充到页面后，就会变成这样：

COPYHTML
<img src="1" onerror="alert('hello world')">

chrome会自动防御这种XSS攻击，不过如果在没有自动防御的浏览器上，还是会被弹窗警告，因此这样可以对引号进行转移：

COPYJAVASCRIPT
var escapeHtmlProperty = function (str) {
    if(!str) return '';
    return str.replace(/"/g,'&quto;').replace(/'/g,''').replace(/ /g,' ');
}

2. CSRF攻击

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

CSRF攻击，我们前端能做的工作很少，需要后端进行防御工作。

1. refer限制： 所有非白名单中的refer请求，全部拒绝；

2. token验证： 客户端发起的请求中带有token，接口验证token的合法性，若token不合法，则认为请求是伪造的；

3. 客户端时间的校验： 若客户端的本地时间与北京标准时间相差较多时，拒绝；

当然后端接口还有更多的防御工作，我们这里也是简单的举几个例子。

3. https协议

在服务器支持https协议时，我们最好把页面按照https的方式开发，要么显式的使用https://或者使用//来让浏览器自己选择。

https协议提供了三个强大的功能来对抗上述的劫持行为：

1. 内容加密。浏览器到腾讯服务器的内容都是以加密形式传输，中间者无法直接查看原始内容。

2. 身份认证。保证用户访问的是腾讯服务，即使被 DNS 劫持到了第三方站点，也会提醒用户没有访问百度服务，有可能被劫持

3. 数据完整性。防止内容被第三方冒充或者篡改。

不过在使用https的过程中，踩了个坑。我在页面中把接口的链接都写成//这种隐式的协议，可是在使用客户端的方法请求接口时发现，客户端的方法不会自动根据页面的协议补全请求接口的协议，需要开发者手动补全协议：

COPYJAVASCRIPT
// 通过 window.location.protocol 获取当前页面的协议
let url = window.location.protocol + '//api.qq.com';

3. 验证码

验证码的作用不必多说，就是为了区分人/机，确定接下来的行为确实是真实用户发起的，而不是机器模拟产生的。

为了防止提现接口被恶意爆刷，我们在用户在提现前，也添加了验证码的功能，验证用户的合法性，确定请求确实是用户主动发起的提现行为。

4. 账户验证

在客户端中的登录过程，是拉起微信登录或QQ登录，然后登录微信账号或QQ账号，用户全部的操作都需要验证微信账号和QQ账号的合法性和危险登录，若判定当前账号是危险账号，则阻止其进一步的操作。

5. 客户端的验证

客户端的验证，是为了保证请求一定是从客户端发起的，而不是从外部某个地方发起的请求。这块在第2部分里也有说明，就是token的验证，客户端发起的任何请求都是带有token的，然后接口验证token的合法性！

写的这么多措施和方法，大部分也是常见的攻击和防御，但是我们依然不能掉以轻心，稍微有点疏忽，就会给用户和我们活动方造成不可挽回 的损失。