常见的web网络攻击处理方案

前言

来到新公司以后，还蛮大的公司，前段后端同事也大都是3年左右工作经验的，但是在遇到被刷手机验证码接口的时候却给出了一些“奇怪”的对策，比如验证手机格式，IOS，Android那边说验证手机机器码。。。
人家都是直接用脚本直接随机生成手机号，机器码什么的好伐。。。
感觉可能是和很多同学平时基本遇不到这样的情况有关吧，我以前的项目的话也有几百万的用户，东西做大了，攻击者就会天天来光顾了，遇到的也就多了。。。所以，我就来做做总结。

分类

本文将介绍一下三种网络攻击的解决方案：

1. XSS
2. CSRF
3. 脚本刷接口

XSS

XSS全称是Cross-site scripting，有点前端安全基础的同学应该都知道。就是通过一些用户可以输入的界面，比如评论，填入一些非法字符，如><script>alert(document.cookie)</script>等类似的方式，导致网页做些这个“史壳郎”想要的一些操作。
怎么防御呢？这种现象的产生原因无非是，前端模板或者后端模板在渲染的时候没有进行字符转译，导致<>这样的字符直接就渲染到了页面上。
所以，我们只需要在渲染前做一次转译，将这些符号转为字符实体就好了。幸运的是，现在的前端库，如vue，react，前端模板ejs，juicer，后端模板smarty，blade等，都已经内部做了转译了，开发者愉快的使用就好了。所以，其实我们完全不用做任何额外的工作。但是，还是理解内部机制比较好。
详细的可以看我在github写的文章，字数不多，但是言简意赅，因为并不喜欢长篇大论的。

CSRF

CSRF全称是Cross-site request forgery。这个的话其实很多公司都不太做这个防御，我问过挺多朋友，他们公司的确并不关心这个。
好吧，，，不过其实，这种攻击的确在如今，对用户或者公司的危害非常小，不过还是要做的，因为，对于网络安全，我们是认真的！
攻击场景的话，比如：网页有一个对作品点赞的功能，点赞提交地址为http://csrf.com/api.like?id=777，然后另外一个网站放了这样一个元素<img src="http://csrf.com/api.like?id=888">，这样的话，一旦用户进入这个bbb.com页面，就会请求csrf.com/api.like这个接口，因为用户的登录信息尚未过期，那就等于给id为888这个作品点赞了。
防御方式：

1. 后端判断referer是否合法（不推荐）
2. 每次请求都要带上token，token是csrf.com页面渲染时一起带过来的，这样的话，如果不在csrf.com页面发起这个点赞请求，token是不存在的，因为就能做到防御了。

这里只简单的介绍了一下，详细的可以看我在github写的文章>>

脚本刷接口

这种攻击方式很简单，最傻瓜的就是在chrome打开控制面板，到console里这么做$.get('/getPhoneVerifyCode')。
最常见的场景就是，也不知道“史壳郎”目的是什么，总会刷网站的手机验证码接口，导致公司在短信接口上话费更多的费用，估计是短信验证码的公司的人干的。。。
防御方式：

1. 目前公认的解决方案，就一种，验证码验证

可是提供验证码的公司那么多，怎么选呢？

还在用这样的验证码吗？
那只要想，分分钟就能被刷爆。这样图片文字识别的算法早烂大街了。

介绍几种比较新型的验证码：

1、智能无感知型：比如谷歌智能验证

2、滑块型：比如极验的滑块

3、图片位置点击型：比如网易云易盾的图中点选

我们以前公司用的是极验验证。用的是它的第二代验证，然后最近发现它居然出了第三代认证，就是“智能无感知型”的认证。

最后，我想说，我真的不是极验公司的码农0 0