1、XSS：跨站脚本攻击
本质：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。
1、存储型攻击步骤：
1，攻击者将恶意代码提交到目标网站的数据库中。
2，用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3，用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等
2、反射型 XSS 的攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
3、DOM 型 XSS 的攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL。
- 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
XSS 攻击有两大要素：
- 攻击者提交恶意代码。
- 浏览器执行恶意代码。
针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？
前端过滤不可行，因为攻击者很容易绕过前端过滤，直接构造请求，譬如postman，gotcha；
后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。前端得到的字符串就是转义后的字符，但是这个内容不能直接用于 Vue 等模板的展示，也不能直接用于内容长度计算。不能用于标题、alert 等。所以，输入过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。
有效解决办法，预防存储型和反射型XSS；
在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
4、转义 HTML
如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。
常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用；
5、预防 DOM 型 XSS 攻击
DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。
在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。
如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。
DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。
- HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
- 验证码：防止脚本冒充用户提交危险操作。
- 对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。
2、CSRF：跨站请求伪造
攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的
1、GET类型的CSRF
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
2、POST类型的CSRF
<form action="http://bank.example/withdraw" method=POST> <input type="hidden" name="account" value="xiaoming" /> <input type="hidden" name="amount" value="10000" /> <input type="hidden" name="for" value="hacker" /> </form> <script> document.forms[0].submit(); </script>
3、CSRF的特点
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF的两个特点：
- CSRF（通常）发生在第三方域名。
- CSRF攻击者不能获取到Cookie等信息，只是使用。
4、同源检测
既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。
在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：
- Origin Header
- Referer Header
如果Origin存在，那么直接使用Origin中的字段确认来源域名就可以。
但是Origin在以下两种情况下并不存在：
- IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions
- 302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上
根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。 对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。
注意，现在主要是使用Origin，优先级高，Referer，且他们的区别是，Origin不含Path部分，且不会像Referer一样存在兼容性问题，Referer还可能被用户禁用和篡改。
而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。
简单总结一下上文的防护策略：
- CSRF自动防御策略：同源检测（Origin 和 Referer 验证）。
- CSRF主动防御措施：Token验证 或者 双重Cookie验证 以及配合Samesite Cookie。
- 保证页面的幂等性，后端接口不要在GET页面中做用户操作。
为了更好的防御CSRF，最佳实践应该是结合上面总结的防御措施方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才能更好的预防CSRF的发生
3、DDoS：分布式拒绝服
1、DDoS是分布式拒绝服务攻击
（Distributed Denial of Service），核心是拒绝服务攻击，通过使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。而攻击的形式，又分为带宽消耗型和资源消耗型。带宽消耗型通过 UDP 洪水攻击、ICMP 洪水攻击以及其他攻击类型；资源消耗型包含 CC攻击、SYN 洪水攻击、僵尸网络攻击等。不同的攻击类型，我们的应对措施有所不同。不过在我们的日常工作中，我们所使用的 DDoS 攻击普遍是带宽消耗型攻击，也就是说，黑客会针对你的服务器发送海量 UDP 包、SYN 包，让你的服务器的带宽被攻击流量占满，无法对外提供服务。举个例子：用户通过网络来访问你的服务器就如同客人过桥来找你，但是由于你的钱只够建立一个双向四车道的桥，但是攻击者派了 100 辆大卡车，堵在你的桥门口，导致没有正常客人能够过桥来找你。
2、理解DDos
Distributed Denial of Service是目前最为强大、最难以防御的攻击方式之一。要理解DDos,得先从DoS说起。最基本的DoS攻击就是利用合理的客户端请求来占用过多的服务器资源，从而使合法用户无法得到服务器的响应。DDoS攻击手段迁在传统的DoS攻击基础之上产生的一类攻击方式，传统的DoS攻击一般是采用一对一的方式，当攻击目标的CPU速度、内存或者网络带宽等各项性能指标不高的情况下，它的效果是明显的。
3、DoS攻击流程
但随着计算机与网络技术的发展，计算机的处理能力显著增加，内存不断增大，同时也出现了千兆级别的网络，这使得DoS攻击逐渐失去了效果。这时分布式拒绝服务攻击手段(DDoS)便应运而生了。理解了DoS攻击后，DDoS的原理就非常简单了，它指的是攻击者借助公共网络，将数量庞大的计算机设备联合起来作为攻击平台，对一个或多个目标发动攻击，从而达到瘫痪目标主机的目的。通常在攻击开始前，攻击者会提前控制大量的用户计算机，称之为“肉鸡",并通过指令使大量的肉鸡在同一时刻对某个主机进行访问，从而达到瘫痪目标主机的目的。
4、阿里云预防策略
阿里云的云盾服务为用户提供 DDoS 攻击的防护能力，在控制成本的情况下，会为用户免费抵御 DDoS 攻击，当攻击超出阈值后，阿里云就会对被攻击 IP 实行屏蔽操作。 阿里云免费为用户提供最高 5Gbps 的恶意流量的攻击防护，你可以在各个产品（ECS、SLB、EIP等）的产品售卖页面看到相关的说明和条款。在其帮助文档也说明了相关的服务的限制。
5、腾讯云策略
腾讯云也为用户提供了免费的 DDoS 攻击防护服务，其免费提供的防御服务的标准如下：外网 IP 被攻击峰值超过 2Gbps 会执行 IP 封堵操作（丢入黑洞），一般黑洞的时长为2小时，大流量攻击时，封堵的时长从24小时到72小时不等。
6、解决方案
资源隔离 == > 资源隔离可以看作是用户服务的一堵防护盾，这套防护系统拥有无比强大的数据和流量处理能力，为用户过滤异常的流量和请求；
用户规则==> 监测用户规则如： 流量类型、请求频率、数据包特征、正常业务之间的延时间隔等。基于这些规则用户可以在满足正常服务本身的前提下更好地对抗七层类的DDoS，并减少服务端的资源开销。
大数据智能分析==>可以基于对海量数据进行分析，进而对合法用户进行模型化，并利用这些指纹特征，如：Http模型特征、数据来源、请求源等，有效地对请求源进行白名单过滤，从而实现对DDoS流量的精确清洗。
资源对抗 ==> 资源对抗也叫“死扛”，即通过大量服务器和带宽资源的堆砌达到从容应对DDoS流量的效果
4、https之中间人攻击
解决办法
Nginx配置文件加上：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
据统计，一个应用有将近80%的代码其实是来自于第三方组件、依赖的类库等，而应用自身的代码其实只占了20%左右。无论是后端服务器应用还是前端应用开发，绝大多数时候我们都是在借助开发框架和各种类库进行快速开发。
举个例子，jQuery就存在多个已知安全漏洞，例如jQuery issue 2432，使得应用存在被XSS攻击的可能。而Node.js也有一些已知的安全漏洞，比如CVE-2017-11499，可能导致前端应用受到DoS攻击。另外，对于前端应用而言，除使用到的前端开发框架之外，通常还会依赖不少Node组件包，它们可能也有安全漏洞。文章来源：https://www.toymoban.com/news/detail-756375.html
手动检查这些第三方代码有没有安全问题是个苦差事，主要是因为应用依赖的这些组件数量众多，手工检查太耗时，好在有自动化的工具可以使用，比如NSP(Node Security Platform)，Snyk等等文章来源地址https://www.toymoban.com/news/detail-756375.html
5、Clickjacking： 点击劫持
解决办法
nginx配置： add_header X-Frame-Options SAMEORIGIN;
到了这里，关于项目实践之浏览器安全（持续更新...）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
