Привет! Давно собирался начать проходить задачи по тестированию уязвимостей забагованного web-приложения bWAPP. В одной из статей писал как развернуть его используя XAMPP. Сейчас в тестовой лаборатории bWAPP (далее — тестовое web-приложение) запускается с виртуальной машины, как одно из приложение входящее в сборку OWASP Broken Web Applications. Тестовое web-приложение охватывает все уязвимости из OWASP Top 10 project. OWASP (Open Web Application Security Project) — открытый проект обеспечения безопасности веб-приложений. Первый блок рассматриваемых уязвимостей — Injection подраздел HTML-Injection. Тип атаки которая позволяет благодаря отсутствию надлежащей обработки ввода данных внедрить на сайт собственный HTML-код. Данной уязвимости подвержены различные формы авторизации, регистрации, обратной связи где есть поля для ввода и отправки данных.

Немного о процессе прохождения. Чтобы начать играть необходимо сначала залогиниться, выбрать уровень и нажать Hack. Изначально уровень сложности самый простой — Low. Всего 3 уровня сложности: low, medium, high. Изменить сложность можно выбрав необходимый нажать на кнопку Set в определенном уровне.

Начнём работать с уязвимостями типа Reflected HTML.

Reflected HTML или другое название — непостоянный HTML. Эта проблема возникает, когда web-приложение немедленно реагирует на пользовательский ввод без проверки того что он ввел. Это приводит к тому, что атакующий может воспользоваться исполняемым кодом браузера внутри одного HTML-ответа. Он называется «Reflected», поскольку вредоносный скрипт не хранится внутри веб-сервера, поэтому злоумышленник должен отправить вредоносную ссылку посредством фишинга, чтобы поймать пользователя в «ловушку».

Уязвимость Reflected HTML может быть легко найдена в полях форм, поисковых системах сайта: здесь тестировщик записывает некоторый произвольный HTML-код в текстовое поле поиска, и, если в web-сайт уязвим, результирующая страница вернется как ответ на эти HTML-сущности.

Reflected HTML можно разделить на три типа:

  • Reflected HTML GET
  • Reflected HTML POST
  • Reflected HTML Current URL
 HTML Injection — Reflected (GET). Level: Low. 

 

В поле Last name был введён html код: <img data-src="http://mtdata.ru/u24/photoD6CE/20262325344-0/original.jpg" /> получился такой вот визуальный дефейс.

 HTML Injection — Reflected (GET). Level: Medium. 

Как видите по полям ввода уже работает фильтр. Предыдущий payload не сработал. По get запросу в Burp видно что строчка <img data-src="http://mtdata.ru/u24/photoD6CE/20262325344-0/original.jpg" />была заэкранирована. Экранирование сработало и когда в первый раз произвели декодирование в url. Но фильтр не сработал при использовании так называемой double url-encoding injection. На сайте снова появился наш очишуительный во всех смыслах кот.

Выше мы работали с GET запросами. GET добавляет значения в URL, включает туда все необходимые данные. Когда используется данный метод, все данные формы кодируются в URL-адрес в качестве параметров строки запроса. С POST данные формы появляются в теле сообщения HTTP-запроса. Переходим на следующий уровень. Та же форма, но будем работать с POST.

 HTML Injection — Reflected (POST). Level: Low. 

Принцип атаки аналогичен описанной в Проведение атаки так же возможно из-за отсутствия фильтрации.

 HTML Injection — Reflected (POST). Level: Medium. 

Прохождение данного уровня аналогично уровню HTML Injection — Reflected (GET). Level: Medium. Так же делаем двойную перекодировку посылаемой строки (строк), только теперь работаем с телом POST-запроса.

На Reflected (GET) и Reflected (POST) с уровнем защиты high провести html инъекции не удаётся. По крайней мере у меня не получилось. Вероятно из-за того что на high уже используется кошерная верификация полей:

<?php
function xss_check_3($data, $encoding = "UTF-8"){ 
    return htmlspecialchars($data, ENT_QUOTES, $encoding);
}
print xss_check_3($data);
?>

Это уже конечно тестирование не методом чёрного ящика, но уж больно хотелось взглянуть на код ) Ок. Следующий уровень — HTML Injection — Reflected (Curent URL). Признаюсь что данное задание поставило в ступор. Долго не мог понять что нужно сделать. Ну выводит система строку: «Your current URL: http://192.168.56.101/bWAPP/htmli_current_url.php» и что?

 HTML Injection — Reflected (Curent URL). Level: Low. 

Уязвимость была в GET запросе в ключе Host. Видимо это значение и нужно было изменить для прохождения. Равно как и в отсутствии фильтрации параметров передаваемых в поля заголовка.

С Reflected багами всё, теперь следующий уровень и новая уязвимость — Stored HTML или персистентная HTML. Благодаря этой уязвимости внедренный вредоносный скрипт постоянно хранится внутри сервера web-приложений, а сервер приложений далее возвращает его обратно пользователю, когда он посещает взломанную страницу. Когда клиент нажимает на полезную нагрузку, которая появляется в виде официальной части сайта, введенный HTML-код будет выполнен браузером.

Данные ошибки чаще всего находил в полях для комментариев на сайтах.

 HTML Injection — Stored (Blog). 

Была внедрена возможность загрузить файл на сервер. Если на целевом сервере нет никакого WAF (файрвол web-приложений), то можно получить доступ ко всей системе. Залит payload, который создал фэйковую форму входа с переадресацией захваченного запроса содержащий логин и пароль жертвы на другой контролируемый сервер с запущенным под определённый порт листенером netcat.

Атака HTTP-injection похожа на межсайтовый скриптинг (XSS). Однако во время эксплутации XSS уязвимости пентестер способен вводить и выполнять коды Javascript, тогда как в HTML-инъекции он работает с HTML-тегами. В одной из следующих статей буду рассказывать про поиск XSS уязвимостей.

Удачи!