Как работает эта атака «Человек посередине»?

Question

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

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

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

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

Answer 1

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

Непосредственно из проекта Джанго

(Я гуглил для одноразового номера, независимого от сеанса .)

Answer 2

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

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

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

Получите действительный токен CSRF

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

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

Измените страницу, обслуживаемую по протоколу HTTP (например, http://foo.com/browse), чтобы иметь форму автоматической отправки, которая отправляется конечной точке HTTPS POST (например, * 1046)*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();">

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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