19

关于其 CSRF 保护的Django 文档指出：

此外，对于 HTTPS 请求，严格的 referer 检查由 CsrfViewMiddleware 完成。这对于解决在 HTTPS 下使用独立于会话的 nonce 时可能发生的中间人攻击是必要的，因为 HTTP 'Set-Cookie' 标头（不幸地）被正在与HTTPS 下的站点。（对 HTTP 请求不进行引用检查，因为在 HTTP 下引用头的存在不够可靠。）

我无法想象这种攻击是如何工作的。有人可以解释一下吗？

更新：
Django 文档中的措辞似乎暗示存在一种特定类型的中间人攻击（我假设这会导致成功的 CSRF）与会话无关的随机数（但不适用于特定于事务） nonce 等，我想）并涉及使用“Set-Cookie”标头。
所以我想知道这种特定类型的攻击是如何工作的。

4

4 回答 4

5

攻击者可以使用 Set-Cookie 设置 CSRF cookie，然后在 POST 表单数据中提供匹配的令牌。由于该站点没有将会话 cookie 绑定到 CSRF cookie，因此无法确定 CSRF 令牌 + cookie 是真实的（对其中一个进行散列等操作将不起作用，因为攻击者只能获得有效的一对直接从该站点获取，并在攻击中使用该对）。

直接来自django项目

（我用谷歌搜索独立于会话的随机数。）

于 2011-05-20T18:21:57.830 回答
2

这是一个这样的中间人攻击的非常详细的描述。下面是一个删节和简化的改编：

假使，假设：

  • 被攻击的站点是foo.com
  • 我们（攻击者）可以 MitM 所有请求
  • 某些页面通过 HTTP 提供（例如http://foo.com/browse）
  • 某些页面通过 HTTPS 提供（例如https://foo.com/check_out），并且这些页面受登录 cookie（带安全集）的保护。请注意，这意味着我们无法窃取用户的登录 cookie。
  • 通过将表单参数与csrftoken cookie 进行比较来保护所有表单。如 django 文档中所述，无论它们是“签名”还是随机随机数，都与这种攻击无关。

获取有效的 CSRF 令牌

MitM 使用该令牌强制攻击者控制的 POST 到 HTTPS 页面：

修改 HTTP 服务页面（例如http://foo.com/browse）以具有提交到 HTTPS POST 端点（例如http://foo.com/check_out）的自动提交表单。还要设置他们的 CSRF cookie 以匹配您的令牌：

<script type="text/javascript">
  function loadFrame(){
    var form=document.getElementById('attackform');
    // Make sure that the form opens in a hidden frame so user doesn't notice
    form.setAttribute('target', 'hiddenframe');
    form.submit();
  }
</script>

<form name="attackform" id="attackform" style="display:none" method="POST" 
      action="http://foo.com/check_out">
  <input type="text" name="expensive-thing" value="buy-it-now"/>
  <input type="text" name="csrf" value="csrf-token-value"/>
</form>

<iframe name="hiddenframe" style="display:none" id="hiddenframe"></iframe>
<XXX onload="loadFrame();">
于 2014-07-08T04:44:08.167 回答
0

Man-In-The-Middle 攻击用非常简单的术语解释。想象一下，两个人正在互相交谈，在他们开始互相交谈之前，他们在开始双向通信之前先握手。当第三个人开始分析两个人如何沟通时（他们的举止是什么？，他们在互相交谈之前是否进行了特殊的握手？，他们喜欢什么时候互相交谈，等等） ，第三个人可以将他/她的交流塑造成他/她可以将自己嵌入到对话中并充当中间人，原来的两个人认为他们正在互相交谈。

现在把这个概念降到极客水平。当 pc、路由器、程序等与网络中的另一个节点通信时，通过身份验证、确认或两者都发生双向通信。如果第三方可以确定所需的事件顺序（会话 id、会话 cookie、流量中的下一个确认/传输/终止序列等），恶意第三方可以将自己的流量镜像为合法节点并将流量泛洪到其中一个合法节点，如果他们得到正确的事件序列，恶意的第三个节点就会被接受为合法节点。

于 2011-05-20T19:57:32.353 回答
0

假设我们有一个 Django 驱动的站点和一个恶意的中间人。在一般情况下，该站点甚至根本不需要提供http://页面来使攻击成功。在 Django 的情况下，它可能需要至少提供一个受 CSRF 保护的页面而不是普通页面http://（请参阅下面的解释）。

  1. 攻击者首先需要获得一个语法有效的 CSRF 令牌。对于某些类型的令牌（例如简单的随机字符串），她可能只能编造一个。对于 Django 的打乱令牌，她可能必须从http://包含 CSRF 的页面中获取一个（例如，在隐藏的表单字段中）。

    关键是 Django 的 CSRF 令牌与用户的会话或任何其他已保存状态无关。Django 将简单地查看 cookie 和表单值（或 AJAX 情况下的标题）之间是否匹配。所以任何有效的令牌都可以。

  2. 用户请求翻页http://。攻击者可以自由修改响应，因为它是未加密的。她Set-Cookie使用她的恶意 CSRF 令牌进行操作，并更改页面以包含一个隐藏表单 - 以及将其提交POSTs到https://端点的 Javascript。当然，该表单包括具有 CSRF 值的字段。

  3. 当用户的浏览器加载响应时，它会存储Set-Cookie头部指定的 CSRF cookie，然后运行 ​​Javascript 来提交表单。它与恶意 CSRF cookie 一起发送POST到https://端点。

    （在相关 RFChttp://中讨论了设置的 cookie将发送到https://端点的“不幸”事实：“主动网络攻击者还可以通过模拟响应并注入标头将 cookie 注入发送到的 Cookie 标头中。HTTPS 服务器at将无法将这些 cookie 与其在 HTTPS 响应中设置的 cookie 区分开来。即使仅使用 HTTPS ，活跃的网络攻击者也可能能够利用此能力发起攻击。”）https://example.com/http://example.com/Set-Cookieexample.comexample.comexample.com

  4. 最后，Django 服务器接收到恶意POST请求。它将 CSRF cookie（由攻击者设置）与表单中的值（由攻击者设置）进行比较，发现它们是相同的。它允许恶意请求。

因此，为了避免这种结果，Django 还会根据标头检查Referer标头（应始终在https://请求中设置）Host。在上面的示例中，该检查将失败，因为攻击者无法伪造Referer标头。浏览器会将其设置为http://攻击者用来托管她的恶意表单的页面，而 Django 将检测该页面与https://它所服务的端点之间的不匹配。

于 2017-01-19T22:33:54.387 回答