- •Отзывы и пожелания
- •Список опечаток
- •Нарушение авторских прав
- •Предисловие
- •Кому адресована эта книга
- •О чем идет речь в книге
- •Как извлечь максимум из книги?
- •Загрузка примеров
- •Загрузка цветных изображений
- •Условные обозначения
- •Атаки на веб-приложения. Введение
- •Правила применения оружия
- •Вопросы конфиденциальности данных
- •Очистка
- •Инструментарий тестировщика
- •Kali Linux
- •Альтернативы Kali Linux
- •Прокси-сервер
- •Burp Suite
- •Zed Attack Proxy
- •Облачная инфраструктура
- •Дополнительные источники
- •Упражнения
- •Резюме
- •Глава 2
- •Эффективное обнаружение
- •Типы тестирования
- •Построение карты сети
- •Masscan
- •hatWeb
- •Nikto
- •CMS-сканеры
- •Эффективная атака методом полного перебора
- •Средства сканирования
- •Постоянное картирование контента
- •Обработка полезной нагрузки
- •«Полиглот»
- •Запутывание (обфускация) кода
- •Дополнительные источники
- •Упражнения
- •Резюме
- •Глава 3
- •Легкая добыча
- •Анализ сети
- •Ищем вход
- •Определение учетных данных
- •Есть способ получше
- •Очистка
- •Дополнительные ресурсы
- •Резюме
- •Глава 4
- •Продвинутые способы атаки с использованием метода полного перебора
- •Распыление подбора пароля
- •Спросим LinkedIn
- •Метаданные
- •Кассетная бомба
- •За семью прокси-серверами
- •ProxyCannon
- •Резюме
- •Глава 5
- •Внедрение файлов
- •Удаленное внедрение файлов
- •Локальное внедрение файлов
- •Внедрение файла для удаленного выполнения кода
- •Резюме
- •Обнаружение и эксплуатация уязвимостей в приложениях с помощью внешних сервисов
- •Распространенный сценарий
- •Командно-контрольный сервер
- •Центр сертификации Let’s Encrypt
- •INetSim
- •Подтверждение
- •Асинхронное извлечение данных
- •Построение выводов на основе анализа данных
- •Резюме
- •Расширение функциональных возможностей Burp Suite
- •Нелегальная аутентификация и злоупотребление учетными записями
- •Швейцарский нож
- •Запутывание кода
- •Collaborator
- •Открытый сервер
- •Выделенный сервер Collaborator
- •Резюме
- •Глава 8
- •Вредоносная сериализация
- •Использование десериализации
- •Атака на пользовательские протоколы
- •Анализ протокола
- •Эксплойт для осуществления атаки
- •Резюме
- •Практические атаки на стороне клиента
- •Правила ограничения домена
- •Совместное использование ресурсов разными источниками
- •Межсайтовый скриптинг
- •Постоянный XSS
- •DOM-модели
- •Межсайтовая подделка запроса
- •BeEF
- •Перехват
- •Атаки с применением методов социальной инженерии
- •Кейлоггер
- •Закрепление в системе
- •Автоматическая эксплуатация
- •Туннелирование трафика
- •Резюме
- •Практические атаки на стороне сервера
- •Внутренние и внешние ссылки
- •Атаки XXE
- •Атака billion laughs
- •Подделка запроса
- •Сканер портов
- •Утечка информации
- •«Слепой» XXE
- •Удаленное выполнение кода
- •Резюме
- •Глава 11
- •Атака на API
- •Протоколы передачи данных
- •SOAP
- •REST
- •Аутентификация с помощью API
- •Базовая аутентификация
- •Ключи API
- •Токены на предъявителя
- •Postman
- •Установка
- •Вышестоящий прокси-сервер
- •Среда выполнения
- •Коллекции
- •Запуск коллекции
- •Факторы атаки
- •Резюме
- •Глава 12
- •Атака на CMS
- •Оценка приложения
- •WPScan
- •sqlmap
- •Droopescan
- •Arachni
- •Взлом кода с помощью бэкдора
- •Закрепление в системе
- •Утечка учетных данных
- •Резюме
- •Глава 13
- •Взлом контейнеров
- •Сценарий уязвимости в Docker
- •Осведомленность о ситуации
- •Взлом контейнера
- •Резюме
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
Межсайтовая подделка запроса
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
E |
|
|
||||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
219 BUY |
|
|
||||||||
|
|
|
|
|
||||||
w Click |
to |
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
- |
|
n |
e |
|
||
|
|
|
|
x cha |
|
|
|
|
Рис.9.6. XSS-атака на базе DOM успешно выполняется
Если мы проверим журнал сервера приложений,то увидим,что наша полезная нагрузка не отправлялась по сети.
root@spider-c2-1:~/web# php -S 0.0.0.0:80
PHP 7.0.30-0+deb9u1 Development Server started Listening on http://0.0.0.0:80
Document root is /var/www/html Press Ctrl-C to quit.
[] 196.247.56.62:59885 [200]: /welcome.html?name=Dade%20Murphy
[] 196.247.56.62:63010 [200]: /welcome.html
Хотя эта атака привела к выполнению той же полезной нагрузки JavaScript, тот факт, что сетевые и серверные элементы управления не могут защитить от этих атак,делает XSS на уровне DOM-модели уникальной. Возможность использовать хештег местоположения для отправки нашей полезной нагрузки даетнам преимущество перед средствами защиты,поскольку они нетолько не смогут остановить атаку с помощью компенсирующих элементов управления на стороне сервера, но даже не смогут увидеть полезную нагрузку.
Межсайтовая подделка запроса
Ранее я кратко упомянул, что браузеры автоматически передают приложениям все связанные с ними куки-файлы. Например, если пользователь прошел аутентификацию на сайте http://email.site,будет создан куки-файл сеанса, который можно использовать для выполнения аутентифицированных запросов. Межсайтовая подделка запроса использует эту функцию взаимодействия с пользователями для взлома чрезмерно доверчивых приложений.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
|
C |
|
E |
|
|
|
||||||
|
|
X |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
|
- |
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
F |
|
|
|
|
|
|
|
t |
|
|||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
NOW! |
|
o |
P |
|
|
|
|
|
NOW! |
o |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
BUY |
|
|
|||||||||
w Click |
to |
BUY 220 Глава 9.Практические атаки на стороне клиента |
w Click |
to |
|
|
|
|
|
|
||||||||||||||
|
|
|
|
|
|
|
|
m |
|
|
|
|
|
|
|
m |
||||||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
|
|
||
|
w |
|
|
|
|
|
|
|
|
|
o |
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
g |
.c |
|
|
. |
|
|
|
|
g |
.c |
|
|||||||
|
|
p |
|
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
e |
Обычно приложения позволяют пользователям обновлять свой профиль с |
|
|
|
e |
|
||||||||||
|
|
|
df |
|
|
n |
|
|
|
|
|
|
|
|
df |
|
|
n |
|
|
|
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
|
-x cha |
|
|
|
|
|
||||
|
|
|
|
|
помощью пользовательских значений, которые передаются через |
GET- или |
|
|
|
|
|
|
|
POST-запросы. Приложение, конечно, проверит, аутентифицирован ли запрос, и, возможно, даже сканирует входные данные, чтобы предотвратить атаки, связанные с SQL-инъекциями или межсайтовым скриптингом.
Рассмотрим сценарий, в котором мы обманом заставили жертву зайти на вредоносный сайтили,возможно,встроили код JavaScript в хорошо известный сайт. Этот конкретный фрагмент кода предназначен для выполнения CSRFатаки и нацелен на приложение http://email.site.
Будучи хакерами,мы немного покопались и поняли,что приложение элект ронной почты позволяетобновлятьсообщение о восстановлении пароля через страницу профиля: http://email.site/profile/.
Когда отправляем изменение в наш собственный тестовый аккаунт, мы видим,что вызывается следующий URL-адрес:
http://email.site/profile/update?recovery_email=test@email.local
Если можем изменить сообщение о восстановлении пароля другого пользователя,то можем сбросить его учетные данные и,возможно,войти в систему в качестве этого пользователя.Воттутвступаетвдействие межсайтовая подделка запроса. Хотя приложение все же проверяет значение адреса электронной почты и запрос должен быть аутентифицирован,других проверок безопаснос ти нет.
В ходе CSRF-атаки во вредоносный сайт внедряется невидимый элемент iframe, img или аналогичный элемент, который отправляет кросс-доменный запрос к приложению-жертве, используя предоставленные злоумышленником значения. Когда браузер жертвы пытается загрузить элемент iframe или img, он также передает куки-файлы сеанса вместе с запросом. С точки зрения приложения это действительный запрос, который разрешено выполнять. Злоумышленники, возможно, не могут прочитать ответ, поскольку он межхостовый (cross-origin) (помните правило ограничения домена?), но ущерб уже нанесен.
На нашем вредоносном сайте мы встраиваем тег <img> с кодом, который указывает на URL-адрес обновления профиля, содержащий в качестве нового значения наш адрес электронной почты.
Типичная CSRF-атака выглядит примерно так, как показано на рис.9.7. Когда пользователь посещает наш вредоносный сайт, изображение пы-
тается загрузиться, отправив аутентифицированный GET-запрос приложе- нию-жертве,обновив адрес электронной почты,на который уходит письмо о восстановлении пароля в приложении электронной почты. Теперь у нас есть возможность запросить сброс пароля для учетной записи жертвы и войти на сайт напрямую.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
Межсайтовая подделка запроса
<img src>="http://email.site/profile/update?recovery_email=attacker@email">
|
|
|
|
|
|
|
|
|
|
Аутентифицированный |
|
|
|
|
|
запрос |
|
|
|
|
|
|
адрес |
Вредоносный сайт |
Жертва |
||||
|
|
|
|
электронной почты |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
E |
|
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
||||
221 BUY |
|
|
|||||||
|
|
|
|
|
|||||
w Click |
to |
|
|
|
|
m |
|||
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
g |
|
|
|
|
|
|
df |
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.9.7. CSRF-атака
Чтобы предотвратить CSRF-атаки, разработчики должны реализовать токеныCSRF.Этоуникальныеслучайныечисла,используемыеодинраз(nonce), генерируемые для каждого запроса к защищенной странице. Когда запрашивается обновление какой-либо части приложения, клиент должен отправить это уникальное значение вместе с запросом,прежде чем изменение данных будет разрешено. Теоретически злоумышленники, внедрившие теги <img> в свой вредоносный сайт,не смогут угадать этоттокен,поэтому CSRF-атака окажется неудачной.ТокеныCSRFявляютсяхорошейзащитойотмежсайтовойподделки запроса, если реализованы должным образом. Прежде всего значение должно быть уникальным,недетерминированным и трудно угадываемым.Небольшое случайноецелоечисло–плохойтокен,потомучтоегоможнолегкоподобратьс помощью метода полного перебора.Хеш MD5 имени пользователя илилюбого другогостатичногопредположительногозначениятакженедостаточнохорош.
Токены CSRF должны быть привязаны к сеансу пользователя,и если этот сеанс завершен,токены также должны быть уничтожены. Если токены являются глобальными, злоумышленники могут сгенерировать их в своих собственных учетных записях и использовать их,чтобы атаковать других.
Токены CSRF также должны быть ограничены по времени. По прошествии достаточного количества времени срок действия токена истечет, и он не должен появляться снова. Если токены передаются через GET-запросы, они могут кешироваться прокси-серверами или браузером, и злоумышленники могут просто собрать старые значения и использовать их повторно.
Когда мы встречаемтокены CSRF в приложении,выбранном в качестве объекта атаки,то должны выполнить проверку на предмет наличия проблем с реализацией. Вы удивитесь, узнав, сколько раз токен CSRF, выданный клиенту, был проигнорирован при передаче обратно на сервер.
Межсайтовая подделка запроса представляет собой интересный тип атаки, и связанные с ней уязвимости часто можно объединить в цепочку с другими проблемами, такими как межсайтовый скриптинг, для осуществления эффективной атаки на конкретную цель.