Как работает атака "человек-в-середине"?

здесь подробное описание одной-такой MitM атаки. Ниже приведена сокращенная и упрощенная адаптация:

предположим, что:

• атакованный сайт foo.com
• мы (злоумышленник) можем MitM все запросы
• некоторые страницы обслуживаются через HTTP (например, http://foo.com/browse)
• некоторые страницы по HTTPS (например,, https://foo.com/check_out), и эти страницы защищены файлом cookie входа в систему (w/Secure set). Обратите внимание, что мы не можем украсть куки пользователя.
• все формы защищены путем сравнения параметра формы с csrftoken cookie. Как отмечается в документах django, для этой атаки не имеет значения, являются ли они "подписанными" или просто случайными.

возьмите действительный токен CSRF

• просто чтение трафика при посещении пользователямиhttp://foo.com/browse
• или, если токены специфичны для формы, мы можем просто войти на сайт с нашей собственной учетной записью и получить действительный токен от http://foo.com/check_out сами по себе.

MitM, чтобы заставить контролируемый злоумышленником пост на страницу 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();">

атака "человек-в-середине" объясняется очень упрощенно. Представьте, что два человека разговаривают друг с другом, и прежде чем начать говорить друг с другом, они пожимают друг другу руки, прежде чем начать двустороннее общение. Когда третий человек начинает анализировать, как эти два человека общаются (каковы их манеры? Они пожимают друг другу руки перед тем, как заговорить?, В какое время они любят разговаривать друг с другом и т. д.), третий человек может формировать его / ее общение до такой степени, что он / она может встраиваться в разговор и выступать в качестве посредника с первоначальными двумя людьми, думая, что они говорят друг с другом.

Теперь возьмите концепцию и довести до уровня выродка. Когда ПК, маршрутизатор, программы и т. д. взаимодействует с другим узлом в сети, существует двусторонняя связь происходит либо с помощью аутентификации, подтверждения или обоих. Если третья сторона может определить последовательность событий, требуется (идентификатор сеанса, файл cookie сеанса, следующая последовательность подтверждения / передачи / прекращения в трафике и т. д.), вредоносная третья сторона может отражать свой собственный трафик как законный узел и наводнять трафик на один из законных узлов, и если они получают правильную последовательность событий, вредоносная третья становится принятой в качестве законного узла.

предположим, у нас есть сайт с питанием от Django и злой человек-в-середине. В общем случае сайт даже не должен был бы обслуживать http:// страницы вообще для атаки, чтобы добиться успеха. В случае Django он, вероятно, должен обслуживать хотя бы одну защищенную CSRF-страницу поверх plain http:// (объяснение см. ниже).

1. злоумышленнику сначала нужно получить синтаксически допустимый токен CSRF. Для некоторых типов токенов (например, простой случайной строки) она может быть в состоянии просто сделать один. Для скремблированных токенов Django ей, вероятно, придется получить один из http:// страница, включающая CSRF (например, в поле скрытой формы).

   ключевым моментом является то, что токены CSRF Django не привязаны к сеансу пользователя или любому другому сохраненному состоянию. Django просто посмотрит, есть ли совпадение между cookie и значением формы (или заголовком В случае AJAX). Поэтому подойдет любой действительный токен.

2. пользователь запрашивает страницу конец http://. Злоумышленник может изменить ответ, так как он не зашифрован. Она делает Set-Cookie С ее вредоносным токеном CSRF и изменяет страницу, чтобы включить скрытую форму-и Javascript, чтобы отправить его-который POSTs до https:// конечной точки. Эта форма, конечно, включает поле со значением CSRF.

3. когда браузер пользователя загружает ответ, он сохраняет файл cookie CSRF, указанный Set-Cookie заголовок, а затем запускает Javascript для отправки форма. Он посылает POST до https:// конечная точка вместе с вредоносным файлом cookie CSRF.

   ("прискорбный" факт, что cookies установлены над http:// будет отправлено в https:// конечные точки обсуждаются в соответствующий RFC: "активный сетевой злоумышленник может также вводить cookies в заголовок Cookie, отправленный в https://example.com/ путем олицетворения ответа от http://example.com/ и впрыскивать Set-Cookie заголовок. Сервер HTTPS на example.com будет невозможно отличить эти файлы cookie из cookies, которые он установил в ответе HTTPS. Активный сетевой злоумышленник может использовать эту возможность для подключения атаки против example.com даже если example.com использует HTTPS исключительно.")

4. наконец, сервер Django получает вредоносный POST запрос. Он сравнивает файл cookie CSRF (установленный злоумышленником) со значением в форме (установленной злоумышленником) и видит, что они одинаковы. Это позволяет злонамеренным запрос.

Итак, чтобы избежать этого результата, Django также проверяет Referer заголовок (который, как ожидается, всегда будет установлен в https:// запросы) против . Эта проверка не будет выполнена в приведенном выше примере, потому что злоумышленник не может подделать . Браузер установит его в http:// страница, которую злоумышленник использовал для размещения ее вредоносной формы, и Django обнаружит несоответствие между этим и https:// конечная точка, которую он выполняет.