Анализ защищенности распределенных информационных систем. bWAPP
Для студентов технических специальностей
Иван Андреевич Трещев
Наталья Андреевна Гулина
Алина Ильлинична Малаховец

Три столпа информационной безопасности – это конфиденциальность, целостность и доступность, которые называются триадой CIA (Confidentiality, Integrity, Availability) Джейсон Андресс

Составитель Владислав Александрович Сериков

Составитель Олеся Владимировна Капчинская

© Иван Андреевич Трещев, 2025

© Наталья Андреевна Гулина, 2025

© Алина Ильлинична Малаховец, 2025

© Владислав Александрович Сериков, составитель, 2025

© Олеся Владимировна Капчинская, составитель, 2025

ISBN 978-5-0068-3273-2

Создано в интеллектуальной издательской системе Ridero

Введение

Мы рассмотрим bWAPP beebox представляющую собой уязвимую виртуальную машину. bWAPP охватывает более 100 известных веб-уязвимостей, включая все риски из списка OWASP Top 10, и предлагает три уровня безопасности (low, medium и high), что позволяет пользователям готовиться к тестам на проникновение. Далее опишем уязвимости из OWASP Top 10.

Инъекция – это попытка злоумышленника отправить данные в приложение таким образом, чтобы изменить смысл команд, отправляемых интерпретатору. Например, наиболее распространенным примером является SQL-инъекция, когда злоумышленник отправляет «101 OR 1 = 1» вместо просто «101». При включении в запрос SQL эти данные меняют значение, возвращая все записи вместо одной. В типичной веб-среде есть множество интерпретаторов, таких как SQL, LDAP, операционная система, XPath, XQuery, язык выражений (EL) и многие другие. Все, что связано с «командным интерфейсом», объединяющим данные в команду, восприимчиво к инъекциям. Даже XSS – это просто форма HTML-инъекции.

Многие организации плохо продумывают меры безопасности для предотвращения атак путем инъекций. Расплывчатые рекомендации по проверке ввода и кодированию вывода не помогут их предотвратить. Вместо этого рекомендуется надежный набор элементов управления, интегрированный в рамки приложений с многоуровневой фильтрацией.

Сломанная аутентификация – это общий термин для нескольких уязвимостей, которые злоумышленники используют для выдачи себя за законных пользователей в сети. В целом, нарушение аутентификации относится к недостаткам в двух областях: управление сеансом и управление учетными данными.

Оба классифицируются как нарушенная аутентификация, потому что злоумышленники могут использовать любой способ маскироваться под пользователя: украденные идентификаторы сеанса или украденные учетные данные.

Злоумышленники используют самые разные стратегии, чтобы воспользоваться этими слабыми местами, начиная от масштабных атак с заполнением учетных данных до узконаправленных схем, направленных на получение доступа к учетным данным конкретного человека.

В последние годы атаки с нарушенной аутентификацией стали причиной многих самых серьезных утечек данных, и эксперты по безопасности бьют тревогу по поводу этой малоизвестной угрозы.

Далее мы сконцентрируемся на практических приемах применения средств перехвата траффика, реверс прокси, средств проведения атак именно для виртуальной инфраструктуры bWAPP для демонстрации основных уязвимостей OWASP Top 10. Авторы предполагают, что читатели самостоятельно развернут на доступном гипервизоре или на hardware образ bWAPP.

1 Broken Auth

1.1 Forgotten Function

Рисунок 1 – Задание 1

Введем произвольный почтовый адрес и посмотрим на вывод.

Рисунок 2 – Введен неверный почтовый ящик

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

Рисунок 3 – Создание пользователя

Рисунок 4 – Введен существующий почтовый ящик

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

1.2 Insecure Login Forms

Рисунок 5 – Задание 2

Введем произвольную пару логин/пароль и посмотрим на вывод.

Рисунок 6 – Введена неверная пара логин/пароль

Посмотрим код страницы

Рисунок 7 – Исходный код страницы

Видим, что на странице есть стандартные логин/пароль. Попробуем их ввести.

Рисунок 8 – Введены данные со страницы

Таким образом данная форма содержит дефолтные логин/пароль (возможно при проверке программист забыл их удалить), что является серьезной уязвимостью.

1.3 logout Management

Рисунок 9 – Задание 3

Попробуем разлогиниться, нажав на гиперссылку «here».

Рисунок 10 – Всплывающее окно

После нажатия появилось всплывающее окно с подтверждением. Подтверждаем выход.

Рисунок 11 – Попали на страницу логина

Если злоумышленник нажмет сейчас кнопку «Назад», то сессия пользователя восстановиться и он попадет на начальную страницу.

Рисунок 12 – Вернулись в сессию

Таким образом при разлогинивании с сайта не происходит очистка сессий пользователя, что позволяет злоумышленнику продолжить ее, просто нажав на кнопку «Назад» или подменив ее на существующую.

1.4 Password Attacks

Рисунок 13 – Задание 4

Попробуем ввести произвольные логин/пароль.

Рисунок 14 – Введены неверные логин/пароль

Попробуем при помощи Burp Suite провести атаку перебора.

Рисунок 15 – Отправляем запрос в Intruder

Рисунок 16 – Выбираем цель атаки

Рисунок 17 – Выбираем тип атаки «Cluster bomb» и добавляем перебираемые параметры (login и admin)

Рисунок 18 – Создаем словарь и правила для первого поля (login)

Рисунок 19 – Создаем словарь и правила для второго поля (password)

Рисунок 20 – Добавляем строки для отсеивания результатов перебора

Нажимаем кнопку «Start attack» и смотрим результат.

Рисунок 21 – Результаты перебора

Из отчета видно, что 15 запрос завершился без ошибки входа. Попробуем ввести данную пару логин/пароль в форму на сайте.

Рисунок 22 – Корректный подбор логина/пароля

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

1.5 Weak Passwords

Рисунок 23 – Задание 5

Попробуем ввести произвольные логин/пароль.

Рисунок 24 – Введены неверные логин/пароль

Попробуем при помощи Burp Suite провести атаку перебора (см. предыдущий пункт). Посмотрим на результат перебора.

Рисунок 25 – Результаты перебора

Из отчета видно, что 13 запрос завершился без ошибки входа. Попробуем ввести данную пару логин/пароль в форму на сайте.

Рисунок 26 – Корректный подбор логина/пароля

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

1.6 Administrative Portals

Рисунок 26 – Задание 6

Посмотрим на URL

Рисунок 27 – URL страницы

При помощи get-запроса передается параметр admin со значением 0. Попробуем изменить это значение на 1.

Рисунок 28 – Разблокированная страница

Таким образом нельзя проводить никакие проверки прав только на стороне пользователей. Всегда следует оставлять дополнительную проверку на стороне сервера.

2 XSS

2.1 Задание 1
1. Reflected (GET)

Рисунок 29 – Задание 1

Введем произвольные имя/фамилию и посмотрим на вывод.

Рисунок 30 – Введены произвольные имя/фамилия

Введенные данные отображаются прямо в html-коде страницы. Попробуем выполнить js-скрипт, чтобы проверить наличие XSS-уязвимости.

Рисунок 31 – Попытка выполнения js-скрипта

Рисунок 32 – Скрипт успешно выполнился

Таким образом на данной странице присутствуем XSS-уязвимость, позволяющая злоумышленнику выполнять произвольный js-код.

2.2 Задание 2
2.1 Reflected (POST)

Рисунок 33 – Задание 2

Введем произвольные имя/фамилию и посмотрим на вывод.

Рисунок 34 – Введены произвольные имя/фамилия

Введенные данные отображаются прямо в html-коде страницы. Попробуем выполнить js-скрипт, чтобы проверить наличие XSS-уязвимости.

Рисунок 35 – Попытка выполнения js-скрипта

Рисунок 36 – Скрипт успешно выполнился

Таким образом на данной странице присутствуем XSS-уязвимость, однако в отличие от предыдущего задания весь ввод передавался при помощи POST-запроса, что также не обезопасило Web-приложение от уязвимости.

2.3 Задание 3
2.3 Reflected (JSON)

Рисунок 37 – Задание 3

Попробуем выполнить стандартную проверку на наличие XSS.

Рисунок 38 – Проверка на наличие XSS

Всплывающее окно не появилось, однако на html-форму отобразился фрагмент js-кода. Посмотрим исходный код страницы.

Рисунок 39 – HTML-код страницы

Как можно заметить наш закрывающий тег </script> закрыл тег, который находился на странице, поэтому вместо выполнения скрипта, предусмотренного разработчиками, мы вывели часть его содержимого. Попробуем добавить дополнительный закрывающий тег </script> в начало нашей проверки.

Рисунок 40 – Выполнение проверки на наличие XSS

Рисунок 41 – Скрипт успешно выполнился

Таким образом при ошибках программистов злоумышленники все-равно могут выполнить произвольный js-код, что ведет к XSS-уязвимости.

2.4 Задание 4
2.4 Reflected (AJAX/JSON)

Рисунок 42 – Задание 4

Попробуем выполнить стандартную проверку на наличие XSS.

Рисунок 43 – Неудачная проверка на наличие XSS

Посмотрим на то, как выполняется код на странице.

Рисунок 44 – Выполняемый js-код

Каждую секунду выполняется метод proceed (), которые получает данные, введенные пользователем и выполняет код из функции handleServerResponse (). В этой функции выполняется запрос при помощи метода eval (). Давайте попробуем проэксплуатировать эту функцию.

Рисунок 45 – Наличие XSS-уязвимости

Таким образом сайт позволяет выполнять произвольный js-код из-за ошибки программиста.

2.5 Задание 5
2.5 Reflected (AJAX/XML)

Рисунок 46 – Задание 5

Попробуем выполнить стандартную проверку на наличие XSS.

Рисунок 47 – Неудачная проверка на наличие XSS

Ничего не произошло. Попробуем закодировать наш ввод при помощи XML-амперсанда.

Рисунок 48 – Закодированная проверка на XSS

Можно заметить, что код принял наш запрос, но некорректно его обработал. Попробуем запрос из предыдущего задания, выполнив предварительно XML-обработку.

Рисунок 49 – Наличие XSS-уязвимости

Таким образом, даже несмотря на простое экранирование, сайт позволяет выполнять произвольный js-код.

2.6 Задание 6
2.6 Reflected (Back Button)

Рисунок 50 – Задание 6

Нажмем на кнопку Go back.

Рисунок 51 – Переход на предыдущую страницу

Посмотрим на исходный код страницы и запрос на страницу.

Рисунок 52 – Исходный код страницы

Рисунок 53 – Запрос к странице с заданием

Заметим, что значение параметра Referer полностью совпадает с тем адресом, который встраивается в параметр onclick кнопки «Go back». Попробуем при загрузке подменить его на произвольный js-скрипт.

Рисунок 54 – Подмена параметра Referer

Рисунок 55 – Измененная страница

Рисунок 56 – Наличие XSS-уязвимости

Таким образом нельзя встраивать ничего в код страницы без должного экранирования.

2.7 Задание 7
2.7 Reflected (Custom Header)

Рисунок 57 – Задание 7

Попробуем в запросе изменить значение заголовка bWAPP.

Рисунок 58 – Подмена значения заголовка bWAPP

Рисунок 58 – Содержимое заголовка встраивается в страницу

Попробуем воспроизвести XSS-инъекцию.

Рисунок 59 – Выполнение XSS-инъекции

Рисунок 60 – Наличие XSS-уязвимости

Таким образом нельзя встраивать ничего в код страницы без должного экранирования, даже если пользователи не могут влиять на содержимое напрямую.

2.8 Задание 8
2.8 Reflected (Eval)

Рисунок 61 – Задание 8

Посмотрим, что выполняется на странице.

Рисунок 62 – HTML-страница

Рисунок 63 – URL-страницы

Внутри eval () выполняется метод, передаваемый GET-запросом. Изменим данный метод.

Рисунок 64 – Подмена значения параметра date

Рисунок 65 – Выполнение произвольного js-кода

Рисунок 66 – Переданная функция подставляется как параметр eval ()

Таким образом нельзя давать пользователям доступ к функции eval ().

2.9 Задание 9
2.9 Reflected (HREF)

Рисунок 67 – Задание 9

Введем произвольное имя

Рисунок 68 – Ввод произвольного имени

Рисунок 69 – Использование имени

Посмотрим на исходный код страницы.

Рисунок 70 – Исходный код страницы

Введенное имя встраивается во все гиперссылки, при нажатии на которые происходит голосование. Попробуем сначала закрыть тег <a>, а затем прописать наш код.

Рисунок 71 – XSS-инъекция

Рисунок 72 – Выполнение произвольного js-кода

Рисунок 73 – Исходный код страницы с использованной уязвимостью

Таким образом любой пользовательский ввод должен быть экранирован.

2.10 Задание 10
2.10 Reflected (Login Form)

Рисунок 74 – Задание 10

Введем произвольные логин/пароль.

Рисунок 75 – Неверные логин/пароль

Попробуем вызвать ошибку SQL

Рисунок 76 – Ошибка SQL выводится на сайт

Попробуем внедрить XSS-инъекцию внутрь SQL-ошибки.

Рисунок 77 – XSS-инъекция внутри ошибочного SQL-запроса

Рисунок 78 – Наличие XSS-уязвимости

Таким образом нельзя выводить тексты никаких ошибок на сайт и пользовательский ввод без должного экранирования.

2.11 Задание 11
2.11 Reflected (PHP_SELF)

Рисунок 79 – Задание 11

Введем произвольные имя/фамилию и посмотрим на вывод.

Рисунок 80 – Введены произвольные имя/фамилия

Введенные данные отображаются прямо в html-коде страницы. Попробуем выполнить js-скрипт, чтобы проверить наличие XSS-уязвимости.

Рисунок 81 – Попытка выполнения js-скрипта

Рисунок 82 – Скрипт успешно выполнился

Таким образом на данной странице присутствуем XSS-уязвимость, позволяющая злоумышленнику выполнять произвольный js-код.

2.12 Задание 12
2.12 Reflected (Referer)

Рисунок 83 – Задание 12

Попробуем подменить Referer в запросе на XSS-инъекцию.

Рисунок 84 – Подмена Referer

Рисунок 85 – Скрипт успешно выполнился

Таким образом на данной странице присутствуем XSS-уязвимость, позволяющая злоумышленнику выполнять произвольный js-код.

2.13 Задание 13
2.13 Reflected (User-Agent)

Рисунок 86 – Задание 13

Попробуем подменить User-Agent в запросе на XSS-инъекцию.

Рисунок 87 – Подмена User-Agent

Рисунок 88 – Скрипт успешно выполнился

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.