Phenquestions
В этой статье вы получите необходимую информацию из приложения, чтобы знать, что атакующий сайт должен делать, чтобы отправлять действительные запросы на уязвимый сервер. Затем вы создадите страницу, которая имитирует законные запросы и заставляет пользователя посетить эту страницу во время аутентификации. Вы также сделаете несколько итераций по основному доказательству концепции, чтобы сделать его более похожим на реальную атаку, когда жертва этого не замечает. Обратите внимание, что файл кода для этой статьи можно найти на гитхабе автора.
Готовиться
Для этой статьи вам понадобится действующая учетная запись пользователя в BodgeIt. В этой статье используется [электронная почта защищена] как жертва:
Как это сделать…
Для начала нужно проанализировать запрос, который вы хотите заставить жертву сделать. Для этого вам понадобится Burp Suite или другой настроенный в браузере прокси:
- Войдите в BodgeIt как любой пользователь и щелкните имя пользователя, чтобы перейти в профиль.
- Измените пароль. Посмотрите, как выглядит запрос в прокси:
Итак, это
ПОЧТАпросьба кhttp: // 192.168.56.11 / bodgeit / пароль.jsp,и имеет только пароль и его подтверждение в теле. - Попробуйте сделать очень простую HTML-страницу, которая воспроизводит этот запрос. Создайте файл (назовите его
csrf-изменить-пароль.html) со следующим содержанием:
- Теперь загрузите этот файл в том же браузере, в котором вы вошли в систему:
- Нажмите "Отправить", и вы будете перенаправлены на страницу профиля пользователя. Он сообщит вам, что пароль был успешно обновлен.
- Хотя это доказывает, что внешний сайт (или локальная HTML-страница, как в данном случае) может выполнить запрос на смену пароля в приложении. По-прежнему маловероятно, что пользователь нажмет на Представлять на рассмотрение Вы можете автоматизировать его и скрыть поля ввода, чтобы скрыть вредоносный контент. Теперь создайте новую страницу на основе предыдущей; назови это
csrf-change-password-scripted.html:Совершенно безобидная страница
Вы можете доверять этой странице.
С вами или вашим аккаунтом BodgeIt ничего плохого не случится.
На этот раз форма имеет параметр ID, и на странице есть скрипт, который отправит свое содержимое, когда страница будет полностью загружена.
- Если вы загрузите эту страницу в том же браузере, в котором запущен сеанс BodgeIt, он автоматически отправит запрос, и после этого отобразится страница профиля пользователя. На следующем снимке экрана обозреватель Отладчикустановить точку останова непосредственно перед тем, как запрос был сделан:
- Последняя попытка выглядит лучше с точки зрения злоумышленника. Вам нужно только, чтобы жертва загрузила страницу, и запрос будет отправлен автоматически, но тогда жертва увидит Ваш пароль был измененсообщение, и это обязательно вызовет тревогу.
- Вы можете дополнительно улучшить атакующую страницу, заставив ее загружать ответ в невидимом фрейме внутри той же страницы. Есть много способов сделать это; быстрый и грязный - установить размер 0 для рамки. Ваш файл будет выглядеть так:
Совершенно безобидная страница
Вы можете доверять этой странице.
С вами или вашим аккаунтом BodgeIt ничего плохого не случится.
Обратите внимание, что целевым свойством формы является iframe, определенный под ним, и что у такого фрейма 0% высоты и ширины.
- Загрузите новую страницу в браузере, где был инициирован сеанс. На этом снимке экрана показано, как выглядит страница при просмотре с помощью браузера Инструменты разработчика:
Обратите внимание, что объект iframe - это только черная линия на странице, и в Inspector вы можете видеть, что он содержит страницу профиля пользователя BodgeIt. - Если вы проанализируете сетевое взаимодействие, осуществляемое вашей страницей CSRF, вы увидите, что она действительно делает запросы на изменение пароля BodgeIt:
Как это работает…
Когда вы отправляете запрос из браузера и уже сохраняете файл cookie, принадлежащий целевому домену, браузер прикрепляет файл cookie к запросу перед его отправкой. Это то, что делает файлы cookie такими удобными в качестве идентификаторов сеансов, но эта характеристика того, как работает HTTP, также делает его уязвимым для атаки, подобной той, которую вы видели в этой статье.
Когда вы загружаете страницу в том же браузере, где у вас есть активный сеанс в приложении, браузер автоматически прикрепляет файл cookie сеанса к этому запросу. Это происходит, даже если это другая вкладка или окно, и эта страница отправляет запрос в домен, в котором инициирован сеанс.
Если сервер не проверяет, действительно ли запросы, которые он получает, исходят из приложения, он позволяет вредоносному сайту совершать звонки от имени законных активных пользователей, которые посещают этот вредоносный сайт при аутентификации в целевом домене.
В тесте на проникновение веб-приложения первый использованный код с двумя текстовыми полями и Представлять на рассмотрение кнопки, может быть достаточно, чтобы продемонстрировать наличие бреши в системе безопасности. Однако тестирование приложения на проникновение может быть частью другого задания, например социальной инженерии или упражнений красной команды. В этом случае потребуются дополнительные усилия, чтобы пользователь-жертва не заподозрил, что что-то происходит.
В этой статье вы использовали JavaScript для автоматизации отправки запроса, установив событие onload на странице и выполнив метод отправки формы в функции обработчика событий. Вы также использовали скрытый iframe для загрузки ответа на смену пароля, поэтому жертва никогда не увидит сообщение о том, что его / ее пароль изменился.
Если вы нашли эту статью интересной, вы можете изучить Поваренная книга по тестированию на проникновение в сеть Kali Linux - второе издание для обнаружения наиболее распространенных веб-уязвимостей и предотвращения их превращения в угрозу безопасности вашего сайта. Поваренная книга по тестированию на проникновение в сеть Kali Linux - второе издание дает вам навыки, необходимые для покрытия всех этапов теста на проникновение - от сбора информации о системе и приложении до выявления уязвимостей с помощью ручного тестирования.
