HTML-инъекция: типы и предотвращение

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

Что такое HTML?

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

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

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

Что такое HTML-инъекция?

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

Тип HTML-инъекции?

Атака почти аналогична XSS, но мы обязательно объясним все атаки. Существует два основных типа внедрения HTML: отраженные и сохраненные.

Отражено

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

Отраженный (GET). Как мы знаем, метод GET используется для получения информации с заданного сервера с использованием заданного URI. Если злоумышленник заметит уязвимость, он может возглавить фишингового злоумышленника, поскольку он может создать фишинговую страницу, связав элементы с URL-адресом и получив учетные данные Vicitm.

Reflected (POST) - злоумышленники не могут вести повреждающую атаку , если уязвимость в одном месте, но данные путешествует по запросу поста. Эта уязвимость может быть затронута только текущим пользователем.

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

Отражено (GET) - низкая настройка

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

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

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

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

Мы можем видеть, что тег успешно отражается и отображается на веб-странице, а также вы можете видеть, что входные данные видны в URL-адресе, что означает, что, добавив параметры html к URL-адресу, злоумышленник может провести фишинговую атаку. А теперь давайте рассмотрим другой пример.

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

<img src=https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_92x30dp.png>

Отражено (GET) - средняя настройка (кодировка URL)

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

Теперь сначала мы закодируем нашу полезную нагрузку с помощью следующего веб-сайта . После получения закодированного URL просто скопируйте его.

Изображение успешно отображается на веб-странице после ввода во входных данных полезных данных в кодировке URL.

Отражено (POST) - Низкое значение

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

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

Отраженный ток (URL)

В большинстве случаев URL-адреса веб-страниц также уязвимы для инъекций. Для этого мы попытаемся изменить текущий URL-адрес веб-страницы с помощью BurpSuite.

Откройте Burpsuite, включите прокси в браузере и запишите ответ из режима блокировки. Мы нашли адрес хоста по умолчанию.

Давайте изменим адрес хоста по мере необходимости и перенаправим запрос.

Мы успешно получили инъекционную уязвимость в веб-приложении путем манипулирования URL-адресом веб-страницы.

Сохраненный HTML

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

Использовать сохраненный HTML

Эта уязвимость также доступна в веб-приложении bWAAP , поэтому мы будем использовать ее для практических целей. Сначала мы рассмотрим поведение веб-приложения, введя простой текст. После ввода имени пользователя мы заметили, что приложения принимают обычный текстовый ввод пользователя.

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

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

Как видите, отраженные ( GET ) и хранимые уязвимости HTML могут привести к фишинг-атаке, и даже это может создать новые уязвимости в веб-приложениях.

Смягчение

Основное правило защиты от HTML-атаки - соответствующая проверка данных.

Каждый ввод следует проверять и контролировать.