网络安全对前端童鞋来说大多数时候都是听其有之，闻之则无，毕竟在现如今前端如火如荼的时代，大多数东西日益成熟，开箱即用，云服务、框架等已经帮我们做了安全方面的防范，不需要我们去太过于关心前端网络安全，作为一个前端爱好者，最近温习一下这部分知识，做了个简单的总结，顺道呈现给各位看官，请注意查收。
xss攻击
Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种
1.1 存储型攻击
存储型攻击常发生在微博论坛等用户发帖、提交文章评论等地方
将恶意代码提交到数据库
数据库将其保存
他用户查看帖子或者评论
服务端返回恶意代码并被拼接到客户端页面
恶意代码可能通过自执行或者用户点击执行来弹出广告或者获取用户的cookie等个人隐私并上报到攻击者数据库
1.2 反射型攻击
反射型攻击主要发生在一些带有诱导性的链接的按钮邮件等
攻击者在一些链接的参数中加入恶意代码并诱导用户点击
用户通过点击将请求参数传入服务端
服务端获取参数并拼接返回给客户端
客户端执行恶意代码冒充用户进行权限操作或者盗取用户的cookie等个人隐私并上报攻击者数据库
1.3 DOM型攻击
攻击者构造出特殊的 URL，其中包含恶意代码。
用户打开带有恶意代码的 URL。
用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM型和反射性都是通过诱导用户点击链接执行，并且都是临时型的，但是反射型属于服务端安全漏洞而DOM型属于客户端安全漏洞
2.如何防范xss攻击
客户端对用户输入的内容进行安全符转义，服务端对上交内容进行安全转义
服务端渲染开启模板引擎自带的 HTML 转义功能。
避免内联事件，尽量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全。
避免拼接 HTML，前端采用拼接 HTML 的方法比较危险，如果框架允许，使用 createElement、setAttribute 之类的方法实现。或者采用比较成熟的渲染框架，如 Vue/React 等。
时刻保持警惕在插入位置为 DOM 属性、链接等位置时，要打起精神，严加防范。
通过 CSP、输入长度配置、接口安全措施等方法，增加攻击的难度，降低攻击的后果。
主动检测和发现，可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。
尽量避免三方跨域提交内容到服务端
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
验证码：防止脚本冒充用户提交危险操作。
CSRF攻击
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
1.1 主动型攻击
受害者访问a.com并在自己浏览器留下a.com的登录态
攻击者诱导受害者访问三方网站b.com
三方网站b.com植有访问a.com接口的恶意代码（删除/增加/修改等）
受害者点击b.com时候，b.com带着a.com的登陆凭证冒充受害用户执行对a.com的恶意操作
1.2 被动型攻击
攻击者在a.com发布带有恶意链接的帖子或者评论（提交对a.com带有增删改的诱导型img/form/a标签）
当其他拥有登录态的受害者点击该评论的恶意链接冒用受害者登录凭证发起攻击
CSRF主要是冒用受害者登录凭证发起恶意的增删改并不会窃取受害者隐私信息
2.如何预防CSRF攻击
1. 禁止三方网站获取cookie,比如设置Chrome的SameSite属性
弊端：SameSite试用阶段，兼容性不是很理想
2. 服务端通过Referer Header 和 Origin Header来进行同源验证
弊端1：攻击者可以部分修改或者隐藏referer
<img src="http://bank.example/withdraw?amount=10000&for=hacker"
referrerpolicy="no-referrer">
弊端2: 某些浏览器或者操作会丢失origin头部，比如302重定向
弊端3：HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。
弊端4：对于被动性攻击并不能识别
其他：某些低版本浏览器对origin和referer并不是很稳定，各种意想不到的结果，极其不稳定
3. 利用token来鉴别，三方跨站请求并不能获取到头部的token，本站的接口在请求前都会在请求头增加token用于身份鉴权，三方请求并不会携带token
弊端1：token鉴权对服务端压力较大，许专门开辟服务器用于token鉴权，耗费服务器成本并且增加请求时间
弊端2：对于页面ajax,fetch等异步请求外的其他请求如form提交，a链接等需要去挨个加token，不能形成统一的token增加入口，存在部分疏漏
相对而言token鉴权算是比较好的一种防护措施
4. 利用双重cookie来认证，在每个请求的参数都附加scrfCookie='随机数'防御参数，并在cookie中混入该防御参数值，服务端将请求头部的cookie中防御cookie参数和请求参数所带的该参数进行比对
弊端：前后分离的代码，后端接口和前端可能不同源，比如前端www.xx.com,后端接口为api.xx.com,前端要拿到后端接口域下的cookie必须将cookie都放在xx.com下面才能保证所有子域都可以拿到，这样反而增加xss攻击风险得不偿失
DOS攻击
DOS攻击通过在网站的各个环节进行攻击，使得整个流程跑不起来，以达到瘫痪服务为目的。最常见的就是发送大量请求导致服务器过载宕机
1. 防范措施
扩容服务器【有钱公司玩的】
进行实时监控，封禁某些恶意密集型请求IP段
增加接口验证，对于某些敏感接口，进行单个IP访问次数限制
进行静态资源缓存，隔离源文件的访问，比如CDN加速
页面劫持
攻击者通过请求的数据传输过程进行数据修改，或者对网站域名进行泛域名解析以重定向网站，在网站中注入广告等
1.1 跳转型劫持，通过泛域名解析等将用户访问的页面打到其他网站，以进行恶意竞争，或者打到一些钓鱼网站进行用户个人利益和其他网站利益名誉侵害
1.2 注入型劫持，对于网站的请求资源进行拦截修改，加入恶意代码或者广告等
2. 如何预防网络劫持
最有效且暴力的直接换成HTTPS，建立安全通道
进行漏洞监控，根据实际情况做出调整
作者：吾乃Jiraiya
链接：https://juejin.im/post/5e84b14151882573be11b795
▼
原创系列推荐
▼
5. Webpack4 入门（上）|| Webpack4 入门（下）
6. MobX 入门（上） || MobX 入门（下）
7. 59篇原创系列汇总
回复“加群”与大佬们一起交流学习~
点这，与大家一起分享本文吧~