The attacker can set the CSRF cookie using Set-Cookie, and then supply a matching token in the POST form data. Since the site does not tie the session cookies to the CSRF cookies, it has no way of determining that the CSRF token + cookie are genuine (doing hashing etc. of one of them will not work, as the attacker can just get a valid pair from the site directly, and use that pair in the attack).
<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();">
Here's a very detailed description of one-such MitM attack. Below is an abridged and simplified adaptation:
some pages are served over HTTPS (e.g., https://foo.com/check_out), and those pages are protected by a log-in cookie (w/Secure set). Note that this means we cannot steal the user's login cookie.
all forms are protected by comparing a form parameter with the csrftoken cookie. As noted in the django docs, it's irrelevant to this attack whether they are "signed" or just random nonces.
or, if the tokens are form-specific, we can just log into the site with our own account and get a valid token from http://foo.com/check_out on our own.
MitM to force attacker-controlled POST to HTTPS page with that token:
Modify an HTTP-served page (e.g., http://foo.com/browse) to have an auto-submitting form that submits to an HTTPS POST end-point (e.g., http://foo.com/check_out). Also set their CSRF cookie to match your token:
<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();">
The Man-In-The-Middle attack explained in very simplistic terms. Imagine two people are talking to each other and before they start talking to each other, they do a handshake before they initiate a two way communication. When a third person starts to analyze how the two individuals how the two people communicate (What are their mannerisms?, Do they do a special handshake before they speak to each other?, What time do they like to talk to each other, etc), the third person can mold his/her communication to the point the he/she can embed themselves into a conversation and act as a mediator with the original two people thinking that they are speaking with each other.
Now take the concept and bring down to the geek level. When a pc, router, programs etc. communicates with another node unto the network, there is two-way communication occurs either by authentication, acknowledgement, or both. If a third party can determine the sequence of events that is required (session id, session cookie, the next sequence of acknowledge/transfer/termination in the traffic, etc), a malicious third party can mirror its own traffic as a legit node and flood the traffic to one of the legit nodes and if they get the right sequence of events down, the malicious third becomes accepted as a legit node.
Let's say we have a Django-powered site and a malicious Man-In-the-Middle. In the general case the site wouldn't even have to serve http:// pages at all for the attack to succeed. In Django's case, it probably needs to serve at least one CSRF-protected page over plain http:// (see below for the explanation).
The attacker first needs to get a syntactically-valid CSRF token. For some types of token (like a simple random string) she might be able to just make one up. For Django's scrambled tokens she will probably have to get one from an http:// page that includes CSRF (e.g. in a hidden form field).
The key point is that Django's CSRF tokens aren't tied to the user's session or any other saved state. Django will simply look to see if there is a match between the cookie and the form value (or header in the case of AJAX). So any valid token will do.
The user requests a page over http://. The attacker is free to modify the response since it's unencrypted. She does a Set-Cookie with her malicious CSRF token, and alters the page to include a hidden form—and the Javascript to submit it—which POSTs to an https:// endpoint. That form, of course, includes the field with the CSRF value.
When the user's browser load the response, it stores the CSRF cookie specified by the Set-Cookie header and then runs the Javascript to submit the form. It sends the POST to the https:// endpoint along with the malicious CSRF cookie.
(The "unfortunate" fact that cookies set over http:// will be sent to https:// endpoints is discussed in the relevant RFC: "An active network attacker can also inject cookies into the Cookie header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header. The HTTPS server at example.com will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against example.com even if example.com uses HTTPS exclusively.")
Finally, the Django server receives the malicious POST request. It compares the CSRF cookie (set by the attacker) to the value in the form (set by the attacker) and sees that they are the same. It allows the malicious request.
So, to avoid that result, Django also checks the Referer header (which is expected to always be set in https:// requests) against the Host header. That check will fail in the example above because the attacker can't forge the Referer header. The browser will set it to the http:// page that the attacker used to host her malicious form, and Django will detect the mismatch between that and the https:// endpoint that it's serving.
发布评论
评论（4）
直接来自 django 项目
（我在 google 上搜索 会话独立随机数。）
Directly from the django project
(I googled for session independent nonce.)
这是非常详细的描述 此类 MitM 攻击。下面是一个删节和简化的改编：
假设：
获取有效的 CSRF 令牌，
MitM 使用该令牌强制攻击者控制的 POST 到 HTTPS 页面：
修改 HTTP 提供的页面（例如，http:/ /foo.com/browse）拥有一个自动提交表单，提交到 HTTPS POST 端点（例如，http://foo.com/check_out）。还设置他们的 CSRF cookie 以匹配您的令牌：
Here's a very detailed description of one-such MitM attack. Below is an abridged and simplified adaptation:
Assume that:
Grab a valid CSRF token
MitM to force attacker-controlled POST to HTTPS page with that token:
Modify an HTTP-served page (e.g., http://foo.com/browse) to have an auto-submitting form that submits to an HTTPS POST end-point (e.g., http://foo.com/check_out). Also set their CSRF cookie to match your token:
中间人攻击的解释非常简单。想象一下两个人正在互相交谈，在他们开始互相交谈之前，他们在发起双向通信之前先握手。当第三个人开始分析两个人如何沟通时（他们的习惯是什么？，他们在互相交谈之前是否做了特殊的握手？，他们喜欢什么时间互相交谈，等等） ，第三人可以塑造他/她的沟通，使他/她可以将自己嵌入到对话中，并充当调解人，让原来的两个人认为他们正在互相交谈。
现在把这个概念带到极客的水平。当电脑、路由器、程序等与网络上的另一个节点进行通信时，会通过身份验证、确认或两者进行双向通信。如果第三方可以确定所需的事件序列（会话 ID、会话 cookie、流量中的下一个确认/传输/终止序列等），则恶意第三方可以将其自己的流量镜像为合法节点，并将流量淹没到合法节点之一，如果它们得到正确的事件序列，则恶意的第三个节点将被接受为合法节点。
The Man-In-The-Middle attack explained in very simplistic terms. Imagine two people are talking to each other and before they start talking to each other, they do a handshake before they initiate a two way communication. When a third person starts to analyze how the two individuals how the two people communicate (What are their mannerisms?, Do they do a special handshake before they speak to each other?, What time do they like to talk to each other, etc), the third person can mold his/her communication to the point the he/she can embed themselves into a conversation and act as a mediator with the original two people thinking that they are speaking with each other.
Now take the concept and bring down to the geek level. When a pc, router, programs etc. communicates with another node unto the network, there is two-way communication occurs either by authentication, acknowledgement, or both. If a third party can determine the sequence of events that is required (session id, session cookie, the next sequence of acknowledge/transfer/termination in the traffic, etc), a malicious third party can mirror its own traffic as a legit node and flood the traffic to one of the legit nodes and if they get the right sequence of events down, the malicious third becomes accepted as a legit node.
假设我们有一个由 Django 驱动的网站和一个恶意中间人。在一般情况下，网站甚至根本不需要提供
http://页面，攻击就会成功。就 Django 而言，它可能需要通过普通的http://提供至少一个受 CSRF 保护的页面（请参阅下面的解释）。攻击者首先需要获取语法上有效的 CSRF 令牌。对于某些类型的令牌（例如简单的随机字符串），她可能可以编造一个。对于 Django 的加扰令牌，她可能必须从包含 CSRF 的
http://页面获取一个（例如，在隐藏的表单字段中）。关键点是 Django 的 CSRF 令牌不与用户的会话或任何其他保存的状态绑定。 Django 将简单地查看 cookie 和表单值（或 AJAX 中的标头）之间是否匹配。因此任何有效的令牌都可以。
用户通过
http://请求页面。由于响应未加密，攻击者可以自由修改响应。她使用恶意 CSRF 令牌执行Set-Cookie，并更改页面以包含隐藏表单 - 以及提交该表单的 Javascript -POST到https://端点。当然，该表单包含具有 CSRF 值的字段。当用户的浏览器加载响应时，它会存储由
Set-Cookie标头指定的 CSRF cookie，然后运行 Javascript 来提交表单。它将POST连同恶意 CSRF cookie 一起发送到https://端点。（通过
http://设置的 cookie 将被发送到https://端点的“不幸”事实在 相关 RFC：“主动网络攻击者还可以将 cookie 注入发送到https://example.com/通过模拟来自http://example.com/的响应并注入Set-CookieHTTPS 标头。example.com的服务器将无法区分这些 cookie 和它在 HTTPS 响应中设置的 cookie，活跃的网络攻击者可能能够利用此功能对example 发起攻击。 .com，即使example.com仅使用 HTTPS。”）最后，Django 服务器收到恶意
POST请求。它将 CSRF cookie（由攻击者设置）与表单中的值（由攻击者设置）进行比较，发现它们是相同的。它允许恶意请求。因此，为了避免这种结果，Django 还会针对
HostReferer 标头（预计始终在https://请求中设置）进行检查代码>标题。在上面的示例中，该检查将失败，因为攻击者无法伪造Referer标头。浏览器会将其设置为攻击者用来托管恶意表单的http://页面，Django 将检测该页面与https://之间的不匹配它正在服务的端点。Let's say we have a Django-powered site and a malicious Man-In-the-Middle. In the general case the site wouldn't even have to serve
http://pages at all for the attack to succeed. In Django's case, it probably needs to serve at least one CSRF-protected page over plainhttp://(see below for the explanation).The attacker first needs to get a syntactically-valid CSRF token. For some types of token (like a simple random string) she might be able to just make one up. For Django's scrambled tokens she will probably have to get one from an
http://page that includes CSRF (e.g. in a hidden form field).The key point is that Django's CSRF tokens aren't tied to the user's session or any other saved state. Django will simply look to see if there is a match between the cookie and the form value (or header in the case of AJAX). So any valid token will do.
The user requests a page over
http://. The attacker is free to modify the response since it's unencrypted. She does aSet-Cookiewith her malicious CSRF token, and alters the page to include a hidden form—and the Javascript to submit it—whichPOSTsto anhttps://endpoint. That form, of course, includes the field with the CSRF value.When the user's browser load the response, it stores the CSRF cookie specified by the
Set-Cookieheader and then runs the Javascript to submit the form. It sends thePOSTto thehttps://endpoint along with the malicious CSRF cookie.(The "unfortunate" fact that cookies set over
http://will be sent tohttps://endpoints is discussed in the relevant RFC: "An active network attacker can also inject cookies into the Cookie header sent tohttps://example.com/by impersonating a response fromhttp://example.com/and injecting aSet-Cookieheader. The HTTPS server atexample.comwill be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack againstexample.comeven ifexample.comuses HTTPS exclusively.")Finally, the Django server receives the malicious
POSTrequest. It compares the CSRF cookie (set by the attacker) to the value in the form (set by the attacker) and sees that they are the same. It allows the malicious request.So, to avoid that result, Django also checks the
Refererheader (which is expected to always be set inhttps://requests) against theHostheader. That check will fail in the example above because the attacker can't forge theRefererheader. The browser will set it to thehttp://page that the attacker used to host her malicious form, and Django will detect the mismatch between that and thehttps://endpoint that it's serving.