web端攻击类型

本文介绍了各种类型的安全攻击和缓解它们的技术。

点击劫持

点击劫持是一种欺骗用户点击链接、按钮等的做法，这与用户认为的不同。例如，这可以用来窃取登录凭据或让用户在不知情的情况下安装恶意软件。（点击劫持有时被称为“用户界面纠正”，尽管这是对“纠正”一词的误用。）

跨站脚本 (XSS)

跨站点脚本 (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 环境（在受害者的浏览器中），payload 被执行。即页面本身并没有改变，但是页面中包含的客户端代码却因为对DOM环境的恶意修改而以意想不到的方式运行。

跨站请求伪造 (CSRF)

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', (e) => { document.querySelector('form').submit(); }</script>

复制到剪贴板

应该使用一些技术来防止这种情况发生：

  • GET 端点应该是幂等的——执行更改但不检索数据的操作应该需要发送 POST（或其他 HTTP 方法）请求。POST 端点不应互换地接受带有查询字符串中的参数的 GET 请求。

  • CSRF 令牌应该通过隐藏的输入字段包含在 <form> 元素中。此令牌对于每个用户应该是唯一的并存储（例如，在 cookie 中），以便服务器可以在发送请求时查找预期值。对于所有可能执行操作的非 GET 请求，应将此输入字段与预期值进行比较。如果不匹配，则应中止请求。

  • 这种保护方法依赖于攻击者无法预测用户分配的 CSRF 令牌。应在登录时重新生成令牌。

  • 用于敏感操作（例如会话 cookie）的 cookie 的生命周期应该很短，并且 SameSite 属性设置为 Strict 或 Lax。（请参阅上面的 SameSite cookie）。在支持浏览器的情况下，这将具有确保会话 cookie 不与跨站点请求一起发送的效果，因此该请求实际上是未经身份验证的应用程序服务器。

  • 应该部署 CSRF 令牌和 SameSite cookie。这可确保所有浏览器都受到保护，并在 SameSite cookie 无法提供帮助的情况下提供保护（例如来自单独子域的攻击）。

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

中间人（MitM）

第三方拦截 Web 服务器和客户端（浏览器）之间的流量，并冒充 Web 服务器以捕获数据（例如登录凭据或信用卡信息）。交通通过，可能有改动。开放 WiFi 网络是执行这种攻击的典型手段。

会话劫持

会话劫持包括访问和滥用用户的已验证会话。这可能通过窃取现有会话的 cookie 或通过欺骗用户（或他们的浏览器）设置具有预定会话 ID 的 cookie 来发生。

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

会话固定

第三方能够确定用户的会话标识符（即，通过读取或设置它），因此作为该用户与服务器交互。窃取 cookie 是一种方法。

回想一下，诸如 application.example.com 之类的子域可以通过设置Domain属性来设置一个 cookie，以便与请求一起发送到 example.com 或其他子域：

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

如果子域上存在易受攻击的应用程序，则此机制可能会在会话固定攻击中被滥用。当用户访问父域（或另一个子域）上的页面时，应用程序可能会信任用户 cookie 中发送的现有值。这可能允许攻击者绕过 CSRF 保护或在用户登录后劫持会话。或者，如果父域不使用HTTP Strict-Transport-includeSubdomains Security WiFi 网络）可以从不存在的子域获得带有 Set-Cookie 标头的响应。最终结果将大致相同，浏览器存储非法 cookie 并将其发送到 example.com 下的所有其他页面。

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

会话侧推

浏览器劫持恶意软件