How does this Man-In-The-Middle attack work?

Question

The Django documentation on its CSRF protection states that:

In addition, for HTTPS requests, strict referer checking is done by CsrfViewMiddleware. This is necessary to address a Man-In-The-Middle attack that is possible under HTTPS when using a session independent nonce, due to the fact that HTTP 'Set-Cookie' headers are (unfortunately) accepted by clients that are talking to a site under HTTPS. (Referer checking is not done for HTTP requests because the presence of the Referer header is not reliable enough under HTTP.)

I have trouble visualizing how this attack works. Could somebody explain?

UPDATE:
The wording in the Django doc seems to imply that there is a specific type of man-in-the-middle attack (which leads to a successful CSRF I'd assume) that works with session independent nonce (but not with transaction specific nonce etc., I suppose) and involves the use of 'Set-Cookie' header.
So I wanted to know how that specific type of attack works.

Answer 1

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).

Directly from the django project

(I googled for session independent nonce.)

Answer 2

Here's a very detailed description of one-such MitM attack. Below is an abridged and simplified adaptation:

Assume that:

• the attacked site is foo.com
• we (the attacker) can MitM all requests
• some pages are served over HTTP (e.g., http://foo.com/browse)
• 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.

Grab a valid CSRF token

• just read the traffic when the users visits http://foo.com/browse
• 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();">