全栈必知系列之网络安全篇

网络安全对前端童鞋来讲大多数时候都是听其有之，闻之则无，毕竟在现现在前端如火如荼的时代，大多数东西日益成熟，开箱即用，云服务、框架等已经帮咱们作了安全方面的防范，不须要咱们去太过于关心前端网络安全，做为一个前端爱好者，最近温习一下这部分知识，作了个简单的总结，顺道呈现给各位看官，请注意查收。

xss攻击

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者经过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种

1.1 存储型攻击

存储型攻击常发生在微博论坛等用户发帖、提交文章评论等地方

1. 将恶意代码提交到数据库
2. 数据库将其保存
3. 他用户查看帖子或者评论
4. 服务端返回恶意代码并被拼接到客户端页面
5. 恶意代码可能经过自执行或者用户点击执行来弹出广告或者获取用户的cookie等我的隐私并上报到攻击者数据库

1.2 反射型攻击

反射型攻击主要发生在一些带有诱导性的连接的按钮邮件等

1. 攻击者在一些连接的参数中加入恶意代码并诱导用户点击
2. 用户经过点击将请求参数传入服务端
3. 服务端获取参数并拼接返回给客户端
4. 客户端执行恶意代码冒充用户进行权限操做或者盗取用户的cookie等我的隐私并上报攻击者数据库

1.3 DOM型攻击

1. 攻击者构造出特殊的 URL，其中包含恶意代码。
2. 用户打开带有恶意代码的 URL。
3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操做。

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 主动型攻击

1. 受害者访问a.com并在本身浏览器留下a.com的登陆态
2. 攻击者诱导受害者访问三方网站b.com
3. 三方网站b.com植有访问a.com接口的恶意代码（删除/增长/修改等）
4. 受害者点击b.com时候，b.com带着a.com的登录凭证冒充受害用户执行对a.com的恶意操做

1.2 被动型攻击

1. 攻击者在a.com发布带有恶意连接的帖子或者评论（提交对a.com带有增删改的诱导型img/form/a标签）
2. 当其余拥有登陆态的受害者点击该评论的恶意连接冒用受害者登陆凭证发起攻击

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所遇到的一个问题，其实内容劫持一开始的出发点是好的，是运营商为了加快用户的访问速度同时减小本身的流量损耗而作的一个缓存机制，用户在像服务器请求数据的时候运营商会把用户的请求转移到这个缓存池中，若是缓存中有就直接返回，没有的话再去像服务器请求而后拦截并缓存服务端给用户的回调数据，这样一来能够极大的下降运营商像服务器请求的次数，也能加快用户的访问，因此出发点是好，可是一些非法的商家对缓存池内部作一次些处理就是直接对返回的内容进行修改，这样一来咱们就会接受到错误的数据