CSRF 保护的真正用途是啥？

Posted 2023-03-10

【中文标题】CSRF 保护的真正用途是啥？

【英文标题】：What is CSRF Protection really for?CSRF 保护的真正用途是什么？

【发布时间】：2012-05-01 19:19:09

【问题描述】：

我很久以前就听说过CSRF，我听到的最多的是：

防止 CSRF 攻击很重要，以免有人自动提交您的表单（使用机器人或其他工具）

嗯，这不是 100% 正确的，是吗？

我已经做了大约 3 年的网络抓取，发出请求非常简单，解析 csrftokenmiddleware 字段并将其与其他字段一起发布。

那么，它的真正用途是什么？

【问题讨论】：

@agf 我刚读了那个问题，我没有看到重复的:(

当然。我现在正在阅读答案... ;)

您描述了一个“匿名”帖子。这一切都是为了保护该帖子不使用真实登录用户的凭据发生。

【参考方案1】：

想象一个电子银行网络应用程序banking.example.com 使用以下表单提交交易：

<form action="/transaction" method="post">
    <input type="text" name="beneficiary"/>
    <input type="text" name="amount"/>
    <input type="submit" value="Pay"/>
</form>

攻击者现在可以使用以下内容在hacker.net 建立一个网站：

<form action="https://banking.example.com/transaction" method="post" style="visibility:hidden">
    <input type="text" name="beneficiary" value="John Doe, Account No. 34-236326-1"/>
    <input type="text" name="amount" value="1000000"/>
    <input type="submit" value="Pay"/>
</form>
<script>
    document.forms[0].submit();
</script>

然后攻击者会诱骗受害者访问hacker.net，这将导致受害者的浏览器向电子银行应用程序发送POST请求，从而向黑客进行大笔交易。这是因为受害者的浏览器很乐意将会话 cookie 与伪造的 POST 请求一起发送到电子银行应用程序。如果表单受到 CSRF 令牌的保护，则攻击者无法使受害者的浏览器发送有效的 POST 请求，因此无法进行攻击。

这种类型的攻击称为跨站点请求伪造 (CSRF) 攻击。

顺便说一句，CSRF 攻击也是人们建议在登录电子银行或其他关键网络应用程序时永远不要访问其他网站的原因。

CSRF 令牌不保护由常规授权用户作为他们自己自动提交的 Web 表单。为了避免这种情况，您可以使用CAPTCHA。

【讨论】：

您认为这与在服务器端验证引荐来源网址有何不同？在不支持 csrf cookie 而只进行此验证的情况下，我仍然可以识别攻击。

好的，我发现了为什么不使用引荐来源网址。它在许多情况下被阻止，因为它有时被认为包含敏感信息。公司及其代理人通常会这样做。但是，如果使用 HTTPS，则更有可能不会被阻止。而且，也有人提到引用者可能会被欺骗。

我在向朋友介绍 CORS 时再次遇到了这个问题。 document.forms[0].submit(); 因为同源策略无论如何都不会工作，对吧？

不，由于历史原因，表单提交不受同源政策的约束。

CORS + 使用 fetch 使 CSRF 无用

【参考方案2】：

是的，您可以抓取表单并获取 CSRF 预防令牌。但是您无法在不抓取网站的情况下提交表单，并且您无法从其他人那里获取令牌然后提交表单——它链接到会话.这正是 CSRF 保护真正防止的，有人欺骗用户提交表单。

---

更一般的 CSRF 描述，最初是为了回复 Django's comments framework and CSRF 而发布的：

CSRF 是一种攻击，其中未经许可访问资源的人欺骗有权访问资源的人。

因此，例如，CSRF 保护可以防止有人诱骗用户发布带有垃圾邮件或恶意软件链接的评论。或者，他们诱骗用户提出的请求可能格式不正确、导致您的网络服务器崩溃，或包含旨在通过验证过程并导致数据库损坏或以其他方式损害您的网站的代码。

因此，如果没有 CSRF 保护，理论上有人可以欺骗已登录的用户提交他们实际上并没有写的评论。

有了 CSRF 保护，Django 将检测到它不是通过您网站上的实际表单提交的真实数据，并将拒绝它。

【参考方案3】：

这是对不同类型场景的保护。 有时，攻击者能够将 javascript、iframe 或 img src-s 注入您的页面，任何登录用户都可以访问的地方。 当用户访问该页面时（假设一个带有 cmets 的页面，并且一条评论请求攻击者发布的链接），该请求是由登录用户的浏览器连同他的 cookie 一起发出的。 CSRF 基本上保护了这种触发提交（简单的客户端提交）。当然，任何攻击者都可以请求页面，解析它以获取令牌并使用令牌创建请求，但不能在登录用户之外执行此操作。

【参考方案4】：

你不能

要发出请求，请解析 csrftokenmiddleware 字段并将其与其他字段一起发布。

因为如果您的服务器配置为properly，则不同域上的 JS 将无法从您的域中获取和使用数据来构造请求。

了解CORS。