Привет, меня зовут Анна Куренова (@SavAnna), в IT я уже девять лет. Начинала как разработчик и тестировщик, потом начала искать уязвимости и перешла в ИБ. Сейчас работаю DevSecOps-инженером и веду телеграм-канал 8ug8eer. В этой статье поговорим о базовых вещах в вебе и некоторых простых уязвимостях, поиск которых под силу даже начинающим. Текст будет полезен новичкам в сфере безопасности и тестирования софта.
Если вам удобнее воспринимать информацию на слух, смело включайте видео. В нем я рассказываю также о том, что не вошло в статью. Заодно советую посмотреть и предыдущие выпуски, в которых другие участники Standoff Bug Bounty делятся историями о том, как они погружались в багхантинг. Всем, кто пропустил предыдущие серии нашего цикла, крайне рекомендую ознакомиться с текстом Олега Уланова (@olegbrain) про поиск уязвимостей SSRF и статьей Александра aka bytehope о багах, связанных с контролем доступа.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите личной информации в интернете. Авторы не несут ответственности за использование опубликованной информации. Помните, что нужно следить за защищенностью своих данных.
Поскольку мы начинаем с азов, то кратко расскажу о принципах работы веб-приложений. В случае рядового пользователя современный интернет работает на основе клиент-серверного взаимодействия. Клиент — это устройство пользователя, например компьютер или смартфон, а сервер — это удаленный компьютер, который обрабатывает запросы клиента.
Для обмена запросами клиент и сервер используют различные протоколы, в нашем случае речь пойдет об HTTP. На основе него также написано много других протоколов, например HTTP Live Streaming (для потоковой передачи видео) или gRPC, разработанный компанией Google. Одно из популярных направлений в поиске уязвимостей — перехват и исследование запросов, с помощью которых «общаются» веб-приложения и браузер. Из них мы узнаем, какие методы HTTP-запросов применяются (GET, POST, PUT, DELETE и т. д.), какие заголовки и параметры передаются в запросах и ответах. Все это мы сейчас и будем применять на практике.
Не все соки одинаково полезны
Нашим подопытным станет магазин соков под незамысловатым названием Juice Shop. Это уже готовое приложение, которое работает на HTTP/1.1. Я развернула его на своем домене, который содержит множество уязвимостей и отлично подходит для обучения. Конечно, для анализа запросов можно ограничиться и стандартными инструментами браузера, такими как DevTools в Chrome.
Для просмотра запросов и работы с ними я использую Burp Suite. Считаю, что это мастхэв для пентестеров и хорошая альтернатива OWASP ZAP. Burp Suite работает как прокси, то есть позволяет видеть все запросы, которые идут на сервер и обратно. А теперь давайте посмотрим, какие базовые уязвимости скрыты в нашем онлайн-магазине. Сразу оговорюсь, что здесь приведу лишь часть примеров, больше багов и теории ищите в записи трансляции.
Первый улов: stored XSS
Начинается все с главной страницы, где мы сразу же видим поле поиска. Первое, что приходит в голову, — попробовать ввести какой-то запрос и посмотреть на результат. Вводим цифру 1 и отмечаем, что сайт выводит наш текст на экран. Далее можно попробовать вписать туда какой-то заголовок (header), в своем примере я введу просто <lol>.
Сайт принял и обработал его, следовательно, он уязвим к HTML-инъекции. Наше приложение неправильно обрабатывает введенные данные и позволяет внедрить сторонний код, который затем интерпретируется браузером.
Теперь я попробую внедрить вредоносный JavaScript-код через запрос на добавление картинки. Впишем в поле поиска запрос на загрузку изображения с адреса X с обработчиком On Error. То есть, если приложение не сможет найти нашу картинку (а по адресу X этого сделать нельзя), на экране появится предупреждение. Таким образом, мы нашли XSS-уязвимость — ведь вместо алерта вполне реально «скормить» нашему сайту вредоносный JavaScript-код. Он будет выполняться каждый раз, когда другие пользователи заходят на страницу. С его помощью я могу попробовать, например, выкрасть чужие данные или перенаправить жертву на вредоносный ресурс.
Вторая уязвимость: IDOR, или BOLA
Продолжим изучать наш Juice Shop и попробуем добавить что-то в корзину, например яблочный сок. С помощью прокси я вижу два запроса — GET (корзины) и POST (товара). Помимо прочего, в них можно увидеть ID пользователя, который совершил эти действия.
Попробуем изменить эти запросы, подставив другой идентификатор, — так мы проверим сайт на наличие уязвимости IDOR (insecure direct object reference), или BOLA (broken object level authorization).
Суть здесь в том, что приложение позволяет получить информацию о любом пользователе. В нашем случае простая подмена ID позволила заглянуть в корзину другого любителя соков, что является очень опасным багом.
Третья находка: подмена контента
Сайт поддерживает загрузку контента. Например, пользователь может прикрепить файл к своему отзыву, что мы и сделаем. Нажимаем «Подтвердить» и смотрим, что нового появилось в нашем прокси. Видим запрос и строку file upload, а в поле Content-Type — значение application/pdf. Проще говоря, браузер сообщает сайту, что собирается загрузить PDF-файл.
Разобравшись, как «общаются» клиент и сервер при обмене файлами, попробуем модифицировать этот запрос. Меняем тип контента и вписываем вместо PDF формат HTML. У нас получилось. А значит, и злоумышленник сможет добавить к отзыву вредоносный скрипт, сайт попробует его обработать и запустит полезную нагрузку. Подставим еще один тип контента и заменим значение в Content-Type на application/XML. Такой файл наше приложение тоже принимает, поэтому есть смысл добавить полезную нагрузку.
Здесь важно знать о том, что документы XML включают такое понятие, как сущность. Это имя, которое будет использовано вместо того или иного содержимого. При этом каждая сущность может преобразовываться в другую. В своем XML-документе я пропишу, что имя and будет заменено на сущность SYSTEM (file:///etc/passwd) с данными о всех зарегистрированных аккаунтах. Сайт обработал наш запрос, а значит, он уязвим к атаке XML External Entity (XXE) — есть возможность выполнить сторонний код через XML-документ. Таким образом можно получить любые файлы, доступные пользователю, от имени которого запущено приложение. Если получится вернуть file:///etc/shadow, то приложение запущено от имени пользователя root.
Заключение
Несмотря на скромные вводные о работе веб-приложений, нам удалось проверить три гипотезы:
Найти уязвимость XSS в поле поиска сайта, что позволяет атаковать всех его пользователей.
Проэксплуатировать IDOR-уязвимость и посмотреть чужие данные.
Найти уязвимость XXE через подмену контента.
Как видите, для этого мне хватило даже базовых знаний о принципах работы веба, а значит, получится и у вас. Если вам тоже нравится тестировать приложения и искать уязвимости, не бойтесь трудностей и смело начинайте свой путь багхантера!