这里就重点说防遍历了，其实也防护CC攻击也是异曲同工的
【理想SRC提交的这个漏洞涉及的接口属于 浏览器AJAX接口】
防护思路：
1：接口进行频率的限制
从图表中可以看到对各种业务场景都是有效的（色块：绿色）
大概的优点和缺点都进行了说明
2：使用JS跳转/JS SET COOKIE
从图表中可以看到，实际业务场景有3个会有问题
优缺点就不说了，大家可以探讨
3：SET COOKIE
优缺点和有问题的业务场景参考图表【当然有的前端js库，没有配置好跳转跟随，其业务场景肯定有问题】
4：验证码（静态验证、动态验证码[需要鼠标交互]）
他的防护效果相对比较好，但是对开发量会有增加，当然还有其他的一些优缺点参考图表
5：强制静态缓存
解释一下，就是请求的内容都进行缓存了，可以根据KEY不同进行缓存（防护效果差），统一一个缓存结果（业务会有影响）
6：参数算法验证【理想采用的这个方式】
其实想说一下优点的，后端没有开发量，因为验证是在WAF上实现的，前端有开发量，优缺点也看到了【理想的碰撞算法已经被解出来了】
PS：我们的js只有压缩，没有混淆和加密
7：Meta跳转、ifream嵌套、flash验证
这些已经不常见了，大家就看一下吧
扩展提升：其实在浏览器还有很多骚操作：鼠标轨迹验证、JS随机延迟(请求分流)、鼠标事件验证、浏览器方言、结合浏览器指纹进行 *风控* 【是技术性风控，非业务性风控】，风控是个争议的话题，团队没有想好就别着急做！！！
