Привет! Давно собирался начать проходить задачи по тестированию уязвимостей забагованного 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 уязвимостей.

Удачи!