Как работает эта атака "Человек-В-Ближнем"?

Документация Django по защите CSRF гласит, что:

Кроме того, для запросов HTTPS, строгая проверка ссылок выполняется CsrfViewMiddleware. Это необходимо для обращения к атаке "человек в центре" это возможно при HTTPS, когда использование независимого сеанса к факту, что HTTP 'Set-Cookie' заголовки (к сожалению) приняты клиентами, которые разговаривают с сайтом под HTTPS. (Проверка референта не для HTTP-запросов, поскольку наличие заголовка Referer не достаточно надежный по HTTP.)

У меня возникли проблемы с визуализацией того, как эта атака работает. Может кто-нибудь объяснить?

UPDATE:
Формулировка в докторе Django, по-видимому, подразумевает, что существует определенный тип атаки "человек в середине" (который приводит к успешному CSRF, который я предполагаю), который работает с независимым от сеанса nonce (но не с конкретным транзаксом nonce и т.д.., Я полагаю) и предполагает использование заголовка "Set-Cookie".
Поэтому я хотел знать, как работает этот тип атаки.

Ответ 1

Злоумышленник может установить cookie CSRF с помощью Set-Cookie, а затем предоставить соответствующий токен в данных формы POST. Поскольку сайт не связывает файлы cookie сеанса с кукисами CSRF, у него нет способа определить, что токен CSRF + cookie является подлинным (выполнение хэширования и т.д. Одного из них не будет работать, так как злоумышленник может просто получить действительную пару с сайта напрямую и использовать эту пару в атаке).

Непосредственно из проекта django

(я googled для независимого от сеанса nonce.)

Ответ 2

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

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

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

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

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

MitM, чтобы заставить атакующую POST на HTTPS страницу с этим токеном:

Измените страницу, обслуживаемую HTTP (например, http://foo.com/browse), чтобы иметь форму автоматической отправки, которая отправляет в конечную точку POST HTTPS (например, http://foo.com/check_out). Также установите их cookie CSRF в соответствие с вашим токеном:

<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();">

Ответ 3

Атака Man-In-The-Middle объясняется очень упрощенно. Представьте, что два человека разговаривают друг с другом, и прежде чем они начинают разговаривать друг с другом, они делают рукопожатие, прежде чем инициируют двустороннее общение. Когда третий человек начинает анализировать, как два человека общаются друг с другом (каковы их манеры?) Выполняют ли они специальное рукопожатие, прежде чем разговаривают друг с другом? В какое время они любят разговаривать друг с другом и т.д.), третий человек может формировать свое сообщение до такой степени, что он может влиться в разговор и действовать как посредник с двумя оригинальными людьми, думающими, что они разговаривают друг с другом.

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

Ответ 4

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

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

Ключевым моментом является то, что токены Django CSRF не привязаны к сеансу пользователя или другому сохраненному состоянию. Django просто посмотрит, есть ли совпадение между файлом cookie и значением формы (или заголовком в случае AJAX). Таким образом, любой действительный токен будет делать.
Пользователь запрашивает страницу над http://. Злоумышленник может свободно изменять ответ, так как он незашифрован. Она делает Set-Cookie со своим вредоносным токеном CSRF и изменяет страницу, чтобы включить скрытую форму, и Javascript для отправки - POSTs к конечной точке https://. Эта форма, конечно, включает в себя поле со значением CSRF.
Когда пользовательский браузер загружает ответ, он сохраняет cookie CSRF, указанный заголовком Set-Cookie, а затем запускает Javascript для отправки формы. Он отправляет POST в конечную точку https:// вместе со вредоносным файлом CSRF.

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

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