Бесплатный фрагмент - Анализ защищенности распределенных информационных систем. bWAPP

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

Введение

Мы рассмотрим 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.2 Insecure Login Forms

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

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

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

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

1.3 logout Management

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

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

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

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

1.4 Password Attacks

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

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

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

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

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

1.5 Weak Passwords

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

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

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

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

1.6 Administrative Portals

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

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

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

2 XSS

2.1 Задание 1

1. Reflected (GET)

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

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

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

2.2 Задание 2

2.1 Reflected (POST)

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

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

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

2.3 Задание 3

2.3 Reflected (JSON)

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

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

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

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

2.4 Задание 4

2.4 Reflected (AJAX/JSON)

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

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

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

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

2.5 Задание 5

2.5 Reflected (AJAX/XML)

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

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

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

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

2.6 Задание 6

2.6 Reflected (Back Button)

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

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

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

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

2.7 Задание 7

2.7 Reflected (Custom Header)

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

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

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

2.8 Задание 8

2.8 Reflected (Eval)

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

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

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

2.9 Задание 9

2.9 Reflected (HREF)

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

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

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

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

2.10 Задание 10

2.10 Reflected (Login Form)

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

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

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

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

2.11 Задание 11

2.11 Reflected (PHP_SELF)

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

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

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

2.12 Задание 12

2.12 Reflected (Referer)

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

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

2.13 Задание 13

2.13 Reflected (User-Agent)

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

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

2.14 Задание 14

2.14 Stored (Blog)

Добавим запись в блог с добавлением js-кода.

Теперь любой пользователь при заходе на страницу выполнит наш скрипт.

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

2.15 Задание 15

2.15 Stored (User- Agent)

Изменим User-Agent в запросе на XSS-инъекцию.

Теперь любой пользователь при заходе на страницу выполнит наш скрипт.

3 HTML Injection

3.1 Задание 1

3.1 HTML Injection — Reflected (GET)

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

3.2 Задание 2

3.2 HTML Injection — Reflected (POST)

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