CSRF 攻击

明天一点
148 阅读12分钟

1、什么是 CSRF 攻击

1.1 举个栗子

了解 CSRF 攻击的最好方法是看一个具体的例子

假设您的银行网站提供了一个表格，允许将资金从当前登录的用户转移到另一个银行帐户。例如，传输表单可能如下所示：

转账表格

<form method="post" action="/transfer">
    <input type="text" name="amount"/>
    <input type="text" name="routingNumber"/>
    <input type="text" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

相应的 HTTP 请求可能如下所示：

传输 HTTP 请求

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded
​
amount=100.00&routingNumber=1234&account=9876

现在假装你在你的银行网站上进行了身份验证，然后在没有注销的情况下访问了一个恶意网站。恶意网站包含一个具有以下形式的 HTML 页面：

邪恶转移表

<form method="post" action="https://bank.example.com/transfer">
    <input type="hidden" name="amount" value="100.00"/>
    <input type="hidden" name="routingNumber" value="evilsRoutingNumber"/>
    <input type="hidden" name="account" value="evilsAccountNumber"/>
    <input type="submit" value="Win Money!"/>
</form>

你喜欢赢钱，所以你点击提交按钮。在此过程中，您无意中将 100 美元转给了恶意用户。发生这种情况是因为，虽然恶意网站无法看到您的 cookie，但与您的银行相关的 cookie 仍会随请求一起发送。

更糟糕的是，整个过程可以通过使用 JavaScript 实现自动化。这意味着您甚至不需要点击按钮。此外，当访问作为XSS 攻击受害者的诚实站点时，它也很容易发生。那么我们如何保护我们的用户免受此类攻击呢？

2、防止 CSRF 攻击

之所以可能发生 CSRF 攻击，是因为受害者网站的 HTTP 请求与攻击者网站的请求完全相同。这意味着无法拒绝来自恶意网站的请求，而只允许来自银行网站的请求。为了防止 CSRF 攻击，我们需要确保请求中存在恶意站点无法提供的内容，以便我们区分这两个请求。

Spring 提供了两种机制来防止 CSRF 攻击：

这两种保护都要求安全方法是幂等的。

2.1 安全方法必须是幂等的

为了防止CSRF起作用，应用程序必须确保“安全”的 HTTP 方法是幂等的。这意味着使用 HTTP GET、HEAD、OPTIONS和TRACE方法的请求不应更改应用程序的状态。

2.2 同步器令牌模式

防止 CSRF 攻击的主要和最全面的方法是使用Synchronizer Token Pattern。这个解决方案是为了确保每个 HTTP 请求除了我们的会话 cookie 之外，还需要一个称为 CSRF 令牌的安全随机生成值出现在 HTTP 请求中。

提交 HTTP 请求时，服务器必须查找预期的 CSRF 令牌并将其与 HTTP 请求中的实际 CSRF 令牌进行比较。如果值不匹配，则应拒绝 HTTP 请求。

这项工作的关键是实际的 CSRF 令牌应该在浏览器不会自动包含的 HTTP 请求的一部分中。例如，在 HTTP 参数或 HTTP 标头中要求实际的 CSRF 令牌将防止 CSRF 攻击。要求 cookie 中的实际 CSRF 令牌不起作用，因为浏览器自动将 cookie 包含在 HTTP 请求中。

我们可以放宽期望，只需要为更新应用程序状态的每个 HTTP 请求提供实际的 CSRF 令牌。为此，我们的应用程序必须确保安全的 HTTP 方法是幂等的。这提高了可用性，因为我们希望允许从外部站点链接到我们的网站。此外，我们不希望在 HTTP GET 中包含随机令牌，因为这会导致令牌泄露。

考虑一下当我们使用 Synchronizer Token Pattern 时我们的例子会发生怎样的变化。假设实际的 CSRF 令牌需要位于名为 的 HTTP 参数中_csrf。我们应用程序的转帐表格如下所示：

同步器令牌形式

<form method="post" action="/transfer">
    <input type="hidden" name="_csrf" value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>
    <input type="text" name="amount"/>
    <input type="text" name="routingNumber"/>
    <input type="hidden" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

该表单现在包含一个带有 CSRF 令牌值的隐藏输入。外部站点无法读取 CSRF 令牌，因为同源策略可确保恶意站点无法读取响应。

相应的转账 HTTP 请求如下所示：

同步器令牌请求

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded
​
amount=100.00&routingNumber=1234&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

您会注意到 HTTP 请求现在包含_csrf具有安全随机值的参数。恶意网站将无法提供正确的_csrf参数值（必须在恶意网站上明确提供），当服务器将实际 CSRF 令牌与预期的 CSRF 令牌进行比较时，传输将失败。

2.3 SameSite 属性

一种防止CSRF攻击的新兴方法是在 cookie 上指定SameSite 属性。服务器可以SameSite在设置 cookie 时指定该属性，以指示当来自外部站点时不应发送 cookie。

Spring Security 不直接控制会话 cookie 的创建，因此不提供对 SameSite 属性的支持。 Spring SessionSameSite为基于 servlet 的应用程序中的属性提供支持。Spring Framework为基于 WebFlux 的应用程序中CookieWebSessionIdResolver的属性提供开箱即用的支持。SameSite

具有该属性的 HTTP 响应标头的示例SameSite可能如下所示：

SameSite HTTP 响应

Set-Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly; SameSite=Lax

SameSite该属性的有效值为：

  • Strict：指定时，来自同一站点的任何请求都包含 cookie。否则，cookie 不包含在 HTTP 请求中。
  • Lax: 指定时，当来自同一站点或请求来自顶级导航时发送 cookie，并且该[方法是幂等的。否则，cookie 不包含在 HTTP 请求中。

考虑如何使用属性保护我们的示例。银行应用程序可以通过在会话 cookie 上指定属性SameSite来防止 CSRF 。

通过SameSite在我们的会话 cookie 上设置属性，浏览器会继续发送JSESSIONID带有来自银行网站的请求的 cookie。但是，浏览器不再发送JSESSIONID带有来自恶意网站的传输请求的 cookie。由于会话不再出现在来自恶意网站的传输请求中，因此应用程序免受 CSRF 攻击。

使用属性来防止 CSRF 攻击时，需要注意一些重要的注意事项。

将SameSite属性设置为Strict可提供更强的防御，但会使用户感到困惑。考虑一个保持登录到托管在social.example.com的社交媒体网站的用户。用户在email.example.org 收到一封电子邮件，其中包含指向社交媒体网站的链接。如果用户单击该链接，他们理所当然地希望通过社交媒体网站的身份验证。但是，如果该SameSite属性是Strict，则不会发送 cookie，因此不会对用户进行身份验证。

我们可以通过实施 gh-7537SameSite来提高针对 CSRF 攻击的保护和可用性。

另一个明显的考虑是，为了使SameSite属性能够保护用户，浏览器必须支持该SameSite属性。大多数现代浏览器都支持 SameSite 属性。但是，仍在使用的旧浏览器可能不会。

出于这个原因，我们通常建议使用该SameSite属性作为深度防御，而不是针对 CSRF 攻击的唯一保护。

3、何时使用 CSRF 保护

什么时候应该使用 CSRF 保护？我们的建议是对普通用户可以通过浏览器处理的任何请求使用 CSRF 保护。如果您正在创建仅供非浏览器客户端使用的服务，您可能希望禁用 CSRF 保护。

3.1 CSRF 保护和 JSON

一个常见的问题是“我需要保护 JavaScript 发出的 JSON 请求吗？” 简短的回答是：这取决于。但是，您必须非常小心，因为存在可能影响 JSON 请求的 CSRF 漏洞。例如，恶意用户可以使用以下形式使用 JSON 创建 CSRF：

JSON 形式的 CSRF

<form action="https://bank.example.com/transfer" method="post" enctype="text/plain">
    <input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
    <input type="submit" value="Win Money!"/>
</form>

这会产生以下 JSON 结构

带有 JSON 请求的 CSRF

{ "amount": 100,
 "routingNumber": "evilsRoutingNumber",
 "account": "evilsAccountNumber",
 "ignore_me": "=test"
}

如果应用程序未验证Content-Type标头，它将暴露于此漏洞。根据设置，验证内容类型的 Spring MVC 应用程序仍然可以通过更新 URL 后缀以结尾来利用.json，如下所示：

CSRF 与 JSON Spring MVC 形式

<form action="https://bank.example.com/transfer.json" method="post" enctype="text/plain">
    <input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
    <input type="submit" value="Win Money!"/>
</form>

3.2 CSRF 和无状态浏览器应用程序

如果我的应用程序是无状态的怎么办？这并不一定意味着您受到保护。事实上，如果用户不需要针对给定请求在 Web 浏览器中执行任何操作，他们很可能仍然容易受到 CSRF 攻击。

例如，考虑一个使用自定义 cookie 的应用程序，该 cookie 包含其中的所有状态以进行身份验证（而不是 JSESSIONID）。当进行 CSRF 攻击时，自定义 cookie 与请求一起发送，其方式与我们之前示例中发送 JSESSIONID cookie 的方式相同。此应用程序容易受到 CSRF 攻击。

使用基本身份验证的应用程序也容易受到 CSRF 攻击。该应用程序容易受到攻击，因为浏览器会自动在任何请求中包含用户名和密码，其方式与我们之前示例中发送 JSESSIONID cookie 的方式相同。

4、CSRF注意事项

4.1 登录

为了防止伪造登录请求，应该保护登录 HTTP 请求免受 CSRF 攻击。防止伪造登录请求是必要的，这样恶意用户就无法读取受害者的敏感信息。攻击执行如下：

  1. 恶意用户使用恶意用户的凭据执行 CSRF 登录。受害者现在被认证为恶意用户。
  2. 然后，恶意用户诱使受害者访问受感染的网站并输入敏感信息。
  3. 该信息与恶意用户的帐户相关联，因此恶意用户可以使用自己的凭据登录并查看受害者的敏感信息。

确保登录 HTTP 请求免受 CSRF 攻击的一个可能的并发症是用户可能会遇到导致请求被拒绝的会话超时。会话超时对于不希望需要会话才能登录的用户来说是令人惊讶的。有关更多信息，请参阅 4.3 CSRF 和会话超时。

4.2 注销

为了防止伪造注销请求，应该保护注销 HTTP 请求免受 CSRF 攻击。防止伪造注销请求是必要的，这样恶意用户就无法读取受害者的敏感信息。有关攻击的详细信息，请参阅此博客文章。

确保注销 HTTP 请求免受 CSRF 攻击的一个可能的并发症是用户可能会遇到导致请求被拒绝的会话超时。会话超时对于不希望有会话注销的用户来说是令人惊讶的。有关详细信息，请参阅 4.3 CSRF 和会话超时。

4.3 CSRF 和会话超时

通常情况下，预期的 CSRF 令牌存储在会话中。这意味着，一旦会话过期，服务器就找不到预期的 CSRF 令牌并拒绝 HTTP 请求。有许多选项（每个选项都有权衡）来解决超时问题：

  • 减少超时的最佳方法是使用 JavaScript 在提交表单时请求 CSRF 令牌。然后使用 CSRF 令牌更新表单并提交。

  • 另一种选择是让用户知道他们的会话即将过期的一些 JavaScript。用户可以单击按钮继续并刷新会话。

  • 最后，预期的 CSRF 令牌可以存储在 cookie 中。这让预期的 CSRF 令牌比会话更有效。

    有人可能会问为什么默认情况下预期的 CSRF 令牌没有存储在 cookie 中。这是因为存在已知的漏洞利用，其中标头（例如，指定 cookie）可以由另一个域设置。这与 Ruby on Rails在标头 X-Requested-With 存在时不再跳过 CSRF 检查的原因相同。有关如何执行漏洞利用的详细信息，请参阅此 webappsec.org 线程。另一个缺点是，通过删除状态（即超时），您将失去在令牌受到威胁时强制使其无效的能力。

4.4 多部分（文件上传）

保护多部分请求（文件上传）免受 CSRF 攻击会导致先有鸡还是先有蛋的问题。为了防止 CSRF 攻击的发生，必须读取 HTTP 请求的主体以获取实际的 CSRF 令牌。但是，读取正文意味着文件已上传，这意味着外部站点可以上传文件。

将 CSRF 保护与 multipart/form-data 结合使用有两种选择：

  • 将 CSRF 令牌放入正文
  • 将 CSRF Token 放在 URL 中

每个选项都有其权衡取舍。

在将 Spring Security 的 CSRF 保护与多部分文件上传集成之前，您应该首先确保您可以在没有 CSRF 保护的情况下上传。有关在 Spring 中使用多部分表单的更多信息，请参阅1.1.11。MultipartFilterSpring 参考和Javadoc的多部分解析器部分。

4.4.1 将 CSRF 令牌放入正文

第一个选项是在请求正文中包含实际的 CSRF 令牌。通过将 CSRF 令牌放在正文中，可以在执行授权之前读取正文。这意味着任何人都可以在您的服务器上放置临时文件。但是，只有授权用户才能提交由您的应用程序处理的文件。一般来说，这是推荐的方法，因为临时文件上传对大多数服务器的影响应该可以忽略不计。

4.4.2 在 URL 中包含 CSRF 令牌

如果不允许未经授权的用户上传临时文件，另一种方法是将预期的 CSRF 令牌作为查询参数包含在表单的 action 属性中。这种方法的缺点是查询参数可能会泄露。更一般地说，将敏感数据放置在正文或标头中以确保其不被泄露被认为是最佳实践。您可以在RFC 2616 第 15.1.3 节“在 URI 中编码敏感信息”中找到更多信息。

4.4.3 HiddenHttpMethodFilter

某些应用程序可以使用表单参数来覆盖 HTTP 方法。例如，以下形式可以将 HTTP 方法视为一个delete而不是一个post.

CSRF 隐藏 HTTP 方法形式

<form action="/process" method="post">
    <!-- ... -->
    <input type="hidden" name="_method" value="delete"/>
</form>

覆盖 HTTP 方法发生在过滤器中。该过滤器必须放在 Spring Security 的支持之前。请注意，覆盖仅发生在 post，因此这实际上不太可能导致任何实际问题。但是，确保将其放置在 Spring Security 的过滤器之前仍然是最佳实践。

avatar
文章
阅读
粉丝