攻击类型

点击劫持是一种欺骗用户点击链接、按钮等的行为，而这些链接、按钮等并非用户认为的真实内容。例如，这可以用来窃取登录凭据或让用户无意中安装恶意软件。（点击劫持有时被称为“用户界面改头换面”，但这是对“改头换面”一词的错误使用。）

跨站脚本 (XSS) 是一种安全漏洞，它允许攻击者将恶意客户端代码注入网站。此代码由受害者执行，并允许攻击者绕过访问控制和冒充用户。根据开放式 Web 应用程序安全项目，XSS 是 2017 年第七大最常见的 Web 应用程序漏洞。

如果 Web 应用程序没有采用足够的验证或编码，这些攻击就会成功。用户的浏览器无法检测到恶意脚本不可信，因此它允许恶意脚本访问任何 Cookie、会话令牌或其他敏感的特定网站信息，或者允许恶意脚本重写 HTML 内容。

跨站脚本攻击通常发生在 1) 数据通过不可信来源（最常见的是 Web 请求）进入 Web 应用程序时，或 2) 动态内容发送到 Web 用户时未经验证是否存在恶意内容。

恶意内容通常包括 JavaScript，但有时也包括 HTML、Flash 或浏览器可以执行的任何其他代码。基于 XSS 的攻击种类几乎无限，但它们通常包括将私有数据（如 Cookie 或其他会话信息）传输给攻击者，将受害者重定向到攻击者控制的网页，或在易受攻击网站的伪装下在用户计算机上执行其他恶意操作。

XSS 攻击可以分为三类：存储型（也称为持久型）、反射型（也称为非持久型）或 DOM 型。

存储型 XSS 攻击

注入的脚本永久存储在目标服务器上。当浏览器发送数据请求时，受害者随后从服务器检索此恶意脚本。

反射型 XSS 攻击

当用户被诱骗点击恶意链接、提交经过特殊制作的表单或浏览恶意网站时，注入的代码会传送到易受攻击的网站。Web 服务器将注入的脚本反射回用户的浏览器，例如在错误消息、搜索结果或任何其他包含作为请求一部分发送到服务器的数据的响应中。浏览器会执行代码，因为它假设响应来自用户已交互过的“可信”服务器。

DOM 型 XSS 攻击

有效负载是由于修改了原始客户端脚本使用的 DOM 环境（在受害者的浏览器中）而执行的。也就是说，页面本身不会发生变化，但页面中包含的客户端代码由于对 DOM 环境的恶意修改而以意外的方式运行。

CSRF（有时也称为 XSRF）是一种相关的攻击类型。攻击者会导致用户的浏览器在未经用户同意或知情的情况下向网站后端发出请求。攻击者可以使用 XSS 有效负载来发起 CSRF 攻击。

维基百科提到了一个关于 CSRF 的好例子。在这种情况下，有人包含一张实际上不是图像的图像（例如在未过滤的聊天或论坛中），实际上它是一个向你的银行服务器发出取款请求。

<img
  src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />

现在，如果你登录了你的银行账户，你的 Cookie 仍然有效（并且没有其他验证），你将在加载包含此图像的 HTML 时立即转账。对于需要 POST 请求的端点，可以以编程方式触发 <form> 提交（可能在不可见的 <iframe> 中），当页面加载时。

<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob" />
  <input type="hidden" name="amount" value="1000000" />
  <input type="hidden" name="for" value="mallory" />
</form>
<script>
  window.addEventListener("DOMContentLoaded", () => {
    document.querySelector("form").submit();
  });
</script>

有一些技术应该用于防止这种情况发生

• GET 端点应该是幂等的——执行更改而不是检索数据的操作应该要求发送 POST（或其他 HTTP 方法）请求。POST 端点不应该互换地接受带有查询字符串中参数的 GET 请求。
• 服务器应该向浏览器提供一个会话唯一的 CSRF 令牌。然后，这个令牌可以在浏览器发布表单时包含（在 <form> 元素中隐藏的输入字段中）。对于所有可能执行操作的非 GET 请求，服务器会将发送的令牌与其为该会话存储的值进行比较。如果出现不匹配，则请求会被中止。
• 这种保护方法依赖于攻击者无法预测用户的分配的 CSRF 令牌。令牌应该在登录时重新生成。
• 用于敏感操作的 Cookie（例如会话 Cookie）应该具有较短的生存期，并且 SameSite 属性 设置为 Strict 或 Lax。在支持的浏览器中，这将确保会话 Cookie 不会与跨站点请求一起发送，并且请求实际上对应用程序服务器未经身份验证。
• 应该部署 CSRF 令牌和 SameSite Cookie。这确保所有浏览器都受到保护，并提供 SameSite Cookie 无法提供帮助的保护（例如来自单独子域的攻击）。

有关更多预防技巧，请参阅 OWASP CSRF 预防备忘单。

第三方拦截 Web 服务器和客户端（浏览器）之间的流量，并冒充 Web 服务器以捕获数据（例如登录凭据或信用卡信息）。流量被传递，可能会进行修改。开放式 Wi-Fi 网络是执行此攻击的典型手段。

会话劫持是指访问和滥用用户的已认证会话。这可能是通过窃取现有会话的 Cookie，或通过欺骗用户（或其浏览器）设置具有预定会话 ID 的 Cookie 来完成的。

可以通过部署严格的内容安全策略来限制泄露途径。

第三方能够确定用户的会话标识符（例如，通过读取或设置它），因此可以像该用户一样与服务器交互。窃取 Cookie 是实现此目的的一种方式。

请记住，诸如 application.example.com 之类的子域可以通过设置 Domain 属性来设置 Cookie，以便与 example.com 或其他子域的请求一起发送

Set-Cookie: CSRF=e8b667; Secure; Domain=example.com

如果易受攻击的应用程序在子域上可用，则此机制可以在会话固定攻击中被滥用。当用户访问父域（或其他子域）上的页面时，应用程序可能会信任用户 Cookie 中发送的现有值。这可能允许攻击者在用户登录后绕过 CSRF 保护或劫持会话。或者，如果父域没有使用 HTTP 严格传输安全 并且 includeSubdomains 设置为开启，则受到主动 MitM 攻击的用户（可能连接到开放式 Wi-Fi 网络）可能会收到来自不存在子域的带有 Set-Cookie 标头的响应。最终结果将大致相同，浏览器会存储非法 Cookie 并将其发送到 example.com 下的所有其他页面。

会话固定应该主要通过在用户身份验证时重新生成会话 Cookie 值（即使已经存在 Cookie）以及通过将任何 CSRF 令牌绑定到用户来缓解。