常见web网络安全知多少
网络安全对大多数童鞋来说大多数时候都是听其有之，闻之则无，毕竟在现如今web开发如火如荼的时代，大多数东西日益成熟，开箱即用，云服务、框架等已经帮我们做了安全方面的防范，不需要我们去太过于关心前端网络安全，作为一个前端爱好者，最近温习一下这部分知识，做了个简单的总结，顺道呈现给各位看官，请注意查收。
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加速
HTTP劫持
1. DNS劫持
DNS劫持又称域名劫持，是指在劫持的网络范围内拦截域名解析的请求，分析请求的域名，把审查范围以外的请求放行，否则返回假的IP地址或者什么都不做使请求失去响应，其效果就是对特定的网络不能访问或访问的是假网址。其实本质就是对DNS解析服务器做手脚，或者是使用伪造的DNS解析服务器
解决办法
DNS的劫持过程是通过攻击运营商的解析服务器来达到目的。我们可以不用运营商的DNS解析而使用自己的解析服务器或者是提前在自己的App中将解析好的域名以IP的形式发出去就可以绕过运营商DNS解析，这样一来也避免了DNS劫持的问题。
2.内容劫持
内容劫持网上很少有提到，这也是在做httpDNS SDK所遇到的一个问题，其实内容劫持一开始的出发点是好的，是运营商为了加快用户的访问速度同时减少自己的流量损耗而做的一个缓存机制，用户在像服务器请求数据的时候运营商会把用户的请求转移到这个缓存池中，如果缓存中有就直接返回，没有的话再去像服务器请求然后拦截并缓存服务端给用户的回调数据，这样一来可以极大的降低运营商像服务器请求的次数，也能加快用户的访问，所以出发点是好，但是一些非法的商家对缓存池内部做一次些处理就是直接对返回的内容进行修改，这样一来我们就会接受到错误的数据