Добро пожаловать обратно, мои начинающие хакеры!
В следующем руководстве из серии «Взлом веб-приложений» мы рассмотрим одну из самых критических уязвимостей веб-приложений — межсайтовый скриптинг (XSS). XSS ежегодно попадает в десятку самых уязвимых веб-приложений по версии OWASP, и не без оснований. Проще говоря, XSS позволяет злоумышленнику отправлять вредоносные скрипты или код на компьютер жертвы. Внедрение такого кода может привести к многочисленным вредоносным действиям.
Если приложение уязвимо к XSS, хакер может разработать URL-адрес, содержащий вредоносный код, и передать его приложению от имени легитимного пользователя. Когда пользователь нажимает на ссылку, отправленную хакером, запрос отправляется приложению. Код или скрипт генерируется на сервере, отправляется в браузер пользователя и выполняется.
Классический метод доказательства концепции (PoC) для XSS заключается в использовании JavaScript для вызова окна предупреждения при запуске скрипта в браузере пользователя. Само по себе это не является вредоносным, а лишь указывает на то, что приложение уязвимо для внедрения кода.
Полезные нагрузки XSS
XSS может доставлять различные типы вредоносных нагрузок. JavaScript — мощный и гибкий язык программирования, поэтому он способен доставлять широкий спектр вредоносных нагрузок. Некоторые из них включают:
1. Всплывающие оповещения
2. Перехват идентификаторов сеанса
3. Загрузка и установка программного обеспечения
4. Перенаправление на другой URL
5. Установка кейлоггера
4. Вызов обратной оболочки, например, Metasploit meterpreter
5. Запуск атак на стороне клиента
Типы XSS
XSS часто делят как минимум на два типа;
1. Отражающий или нестойкий
2. Постоянный или хранимый
Рефлективный XSS-код обычно представляет собой код, который «отражается» обратно на веб-страницу и не сохраняется после однократного использования. Постоянный или хранимый XSS-код, как следует из названия, хранится внутри приложения и может быть запущен несколько раз несколькими пользователями.
В этом уроке мы будем использовать DVWA для демонстрации этих атак и уязвимостей.
Шаг №1. Подключитесь к DVWA
Для начала загрузите систему с установленным DVWA. Я использую Metasploitable, но вы можете использовать любую систему с установленным DVWA. Затем подключитесь к DVWA через браузер в системе Kali.
Шаг №2 Установите низкий уровень безопасности
В этом руководстве мы будем использовать простую XSS-атаку, которую обычно проверяют современные безопасные веб-приложения. Для демонстрации мы отключим этот процесс очистки. Для этого нам нужно установить уровень безопасности на нашем DVWA на «низкий».
Шаг №3. Отраженные XSS-атаки
Для выполнения отражённой XSS-атаки жертва должна выполнить определённое действие, например, нажать на ссылку, выполнить поиск или воспользоваться другой функцией. Кроме того, жертва должна быть авторизована в приложении на момент перехода по ссылке.
Для начала перейдите на страницу Reflected XSS в DVWA, как показано ниже.
А теперь введите своё имя. Я ввёл своё имя в форме «Occupytheweb».
Как вы можете видеть выше, после нажатия кнопки «Отправить» приложение возвращается и приветствует меня фразой «Hello Occupytheweb».
На этот раз мы введём некий скрипт и посмотрим, сможет ли приложение его выполнить. Вот скрипт, который нужно ввести:
<script>alert(“Привет, хакеры, восстаньте!”) </script)
Беглый просмотр этого скрипта показывает, что мы запускаем окно оповещения, в котором говорится: «Привет, хакеры, восстаньте!»
Итак, вместо того, чтобы вводить свое имя в форму, давайте введем этот скрипт.
Теперь нажмите «Отправить».
Как видите, скрипт был выполнен, и появилось окно с сообщением «Hello Hackers-Arise». Очевидно, это приложение уязвимо для атаки Reflected XSS!
Отражённая XSS-атака — это одноразовая атака. Скрипт будет выполнен в браузере любого, кто кликнет по ссылке.
Шаг №4 Атака через адресную строку URL
При запуске отражённой XSS-атаке вы видите, что URL-адрес, созданный в результате атаки, изменился. Мы могли бы использовать этот URL-адрес для выполнения атаки. Злоумышленник мог бы отправить эту ссылку жертве для выполнения атаки. Для демонстрации просто скопируйте и вставьте URL-адрес в другую вкладку браузера.
Как вы можете видеть, это также хорошо работает и для запуска атаки Reflected XSS.
Шаг №5. Атака сеансовых cookie-файлов
Хотя создание всплывающего окна с предупреждением интересно и подтверждает концепцию, оно не даёт злоумышленнику никакой ценности. Что, если бы мы могли заставить окно с предупреждением получать cookie-файл сеанса жертвы? Таким образом, злоумышленник мог бы использовать этот cookie-файл для аутентификации в приложении как законный пользователь.
В этом случае мы создадим скрипт, который генерирует оповещение, захватывает cookie-файл сеанса и отображает его.
Следующий скрипт должен сделать именно это.
<script>оповещение(document.cookie)</script>
Как вы можете видеть, когда мы запускаем этот скрипт, приложение захватывает и отображает идентификатор сеанса пользователя, который затем может быть использован для аутентификации злоумышленника в приложении!
Шаг №6. Постоянные или сохраненные XSS-атаки
Постоянная или хранимая XSS-атака существенно отличается от отражённой XSS-атаки. Что особенно важно, злоумышленнику не нужно использовать социальную инженерию, чтобы заставить жертву кликнуть по URL-адресу, он просто сохраняет вредоносный код в приложении. Таким образом, каждый посетитель вредоносной веб-страницы станет жертвой этой атаки.
Постоянные XSS-атаки гораздо более вредоносны и разрушительны, чем отраженные атаки. Они способны атаковать множество жертв и внедрять вредоносное ПО или другие полезные данные в целевую систему.
Начнем с нажатия на приложение DVWA Stored Cross Site Scripting.
Это приложение представляет собой «гостевую книгу» веб-приложения, где каждый пользователь может ввести своё имя и оставить комментарий. Очевидно, что гостевая книга будет хранить введённую информацию в базе данных (в данном случае MySQL). Если мы сможем отправить скрипт в эту базу данных, наш скрипт будет сохранён там и будет запускаться снова и снова по мере того, как пользователи будут посещать и использовать гостевую книгу.
Давайте начнём с ввода нашего имени — OTW. Затем введём немного кода Javascript.
<script>alert(«Hackers-Arise — ЛУЧШИЙ»)</script>
Если этот скрипт запустится, он откроет окно с предупреждением, в котором будет очевидно: «Hackers-Arise — ЛУЧШИЙ».
Когда мы нажимаем «Подписать гостевую книгу», открывается окно с предупреждением, в котором говорится то, что, как мы все знаем, является правдой.
Поскольку приложение сохраняет эту информацию в серверной базе данных, мы можем заставить этот скрипт запускаться всякий раз, когда кто-либо входит в гостевую книгу.
Давайте проверим это, войдя как другой гость и введя другое сообщение. В данном случае я войду как «Джон Доу» и оставлю сообщение: «Я так рад быть здесь».
Когда Джон Доу нажимает «Оставить запись в гостевой книге», он получает то же самое сообщение: «Hackers-Arise — ЛУЧШИЙ». Наша XSS-атака сохранилась в базе данных, и теперь каждый гость будет приветствоваться нашим сообщением!
Межсайтовый скриптинг (XSS) — одна из самых серьёзных и вредоносных уязвимостей в веб-приложениях. Эти атаки способны внедрить любое количество вредоносных данных в браузер жертвы и, в конечном итоге, в её компьютерную систему.
В следующем руководстве из серии «Взлом веб-приложений» мы рассмотрим одну из самых критических уязвимостей веб-приложений — межсайтовый скриптинг (XSS). XSS ежегодно попадает в десятку самых уязвимых веб-приложений по версии OWASP, и не без оснований. Проще говоря, XSS позволяет злоумышленнику отправлять вредоносные скрипты или код на компьютер жертвы. Внедрение такого кода может привести к многочисленным вредоносным действиям.
Если приложение уязвимо к XSS, хакер может разработать URL-адрес, содержащий вредоносный код, и передать его приложению от имени легитимного пользователя. Когда пользователь нажимает на ссылку, отправленную хакером, запрос отправляется приложению. Код или скрипт генерируется на сервере, отправляется в браузер пользователя и выполняется.
Классический метод доказательства концепции (PoC) для XSS заключается в использовании JavaScript для вызова окна предупреждения при запуске скрипта в браузере пользователя. Само по себе это не является вредоносным, а лишь указывает на то, что приложение уязвимо для внедрения кода.
Полезные нагрузки XSS
XSS может доставлять различные типы вредоносных нагрузок. JavaScript — мощный и гибкий язык программирования, поэтому он способен доставлять широкий спектр вредоносных нагрузок. Некоторые из них включают:
1. Всплывающие оповещения
2. Перехват идентификаторов сеанса
3. Загрузка и установка программного обеспечения
4. Перенаправление на другой URL
5. Установка кейлоггера
4. Вызов обратной оболочки, например, Metasploit meterpreter
5. Запуск атак на стороне клиента
Типы XSS
XSS часто делят как минимум на два типа;
1. Отражающий или нестойкий
2. Постоянный или хранимый
Рефлективный XSS-код обычно представляет собой код, который «отражается» обратно на веб-страницу и не сохраняется после однократного использования. Постоянный или хранимый XSS-код, как следует из названия, хранится внутри приложения и может быть запущен несколько раз несколькими пользователями.
В этом уроке мы будем использовать DVWA для демонстрации этих атак и уязвимостей.
Шаг №1. Подключитесь к DVWA
Для начала загрузите систему с установленным DVWA. Я использую Metasploitable, но вы можете использовать любую систему с установленным DVWA. Затем подключитесь к DVWA через браузер в системе Kali.
Шаг №2 Установите низкий уровень безопасности
В этом руководстве мы будем использовать простую XSS-атаку, которую обычно проверяют современные безопасные веб-приложения. Для демонстрации мы отключим этот процесс очистки. Для этого нам нужно установить уровень безопасности на нашем DVWA на «низкий».
Шаг №3. Отраженные XSS-атаки
Для выполнения отражённой XSS-атаки жертва должна выполнить определённое действие, например, нажать на ссылку, выполнить поиск или воспользоваться другой функцией. Кроме того, жертва должна быть авторизована в приложении на момент перехода по ссылке.
Для начала перейдите на страницу Reflected XSS в DVWA, как показано ниже.
А теперь введите своё имя. Я ввёл своё имя в форме «Occupytheweb».
Как вы можете видеть выше, после нажатия кнопки «Отправить» приложение возвращается и приветствует меня фразой «Hello Occupytheweb».
На этот раз мы введём некий скрипт и посмотрим, сможет ли приложение его выполнить. Вот скрипт, который нужно ввести:
<script>alert(“Привет, хакеры, восстаньте!”) </script)
Беглый просмотр этого скрипта показывает, что мы запускаем окно оповещения, в котором говорится: «Привет, хакеры, восстаньте!»
Итак, вместо того, чтобы вводить свое имя в форму, давайте введем этот скрипт.
Теперь нажмите «Отправить».
Как видите, скрипт был выполнен, и появилось окно с сообщением «Hello Hackers-Arise». Очевидно, это приложение уязвимо для атаки Reflected XSS!
Отражённая XSS-атака — это одноразовая атака. Скрипт будет выполнен в браузере любого, кто кликнет по ссылке.
Шаг №4 Атака через адресную строку URL
При запуске отражённой XSS-атаке вы видите, что URL-адрес, созданный в результате атаки, изменился. Мы могли бы использовать этот URL-адрес для выполнения атаки. Злоумышленник мог бы отправить эту ссылку жертве для выполнения атаки. Для демонстрации просто скопируйте и вставьте URL-адрес в другую вкладку браузера.
Как вы можете видеть, это также хорошо работает и для запуска атаки Reflected XSS.
Шаг №5. Атака сеансовых cookie-файлов
Хотя создание всплывающего окна с предупреждением интересно и подтверждает концепцию, оно не даёт злоумышленнику никакой ценности. Что, если бы мы могли заставить окно с предупреждением получать cookie-файл сеанса жертвы? Таким образом, злоумышленник мог бы использовать этот cookie-файл для аутентификации в приложении как законный пользователь.
В этом случае мы создадим скрипт, который генерирует оповещение, захватывает cookie-файл сеанса и отображает его.
Следующий скрипт должен сделать именно это.
<script>оповещение(document.cookie)</script>
Как вы можете видеть, когда мы запускаем этот скрипт, приложение захватывает и отображает идентификатор сеанса пользователя, который затем может быть использован для аутентификации злоумышленника в приложении!
Шаг №6. Постоянные или сохраненные XSS-атаки
Постоянная или хранимая XSS-атака существенно отличается от отражённой XSS-атаки. Что особенно важно, злоумышленнику не нужно использовать социальную инженерию, чтобы заставить жертву кликнуть по URL-адресу, он просто сохраняет вредоносный код в приложении. Таким образом, каждый посетитель вредоносной веб-страницы станет жертвой этой атаки.
Начнем с нажатия на приложение DVWA Stored Cross Site Scripting.
Это приложение представляет собой «гостевую книгу» веб-приложения, где каждый пользователь может ввести своё имя и оставить комментарий. Очевидно, что гостевая книга будет хранить введённую информацию в базе данных (в данном случае MySQL). Если мы сможем отправить скрипт в эту базу данных, наш скрипт будет сохранён там и будет запускаться снова и снова по мере того, как пользователи будут посещать и использовать гостевую книгу.
Давайте начнём с ввода нашего имени — OTW. Затем введём немного кода Javascript.
<script>alert(«Hackers-Arise — ЛУЧШИЙ»)</script>
Если этот скрипт запустится, он откроет окно с предупреждением, в котором будет очевидно: «Hackers-Arise — ЛУЧШИЙ».
Когда мы нажимаем «Подписать гостевую книгу», открывается окно с предупреждением, в котором говорится то, что, как мы все знаем, является правдой.
Поскольку приложение сохраняет эту информацию в серверной базе данных, мы можем заставить этот скрипт запускаться всякий раз, когда кто-либо входит в гостевую книгу.
Давайте проверим это, войдя как другой гость и введя другое сообщение. В данном случае я войду как «Джон Доу» и оставлю сообщение: «Я так рад быть здесь».
Когда Джон Доу нажимает «Оставить запись в гостевой книге», он получает то же самое сообщение: «Hackers-Arise — ЛУЧШИЙ». Наша XSS-атака сохранилась в базе данных, и теперь каждый гость будет приветствоваться нашим сообщением!
Межсайтовый скриптинг (XSS) — одна из самых серьёзных и вредоносных уязвимостей в веб-приложениях. Эти атаки способны внедрить любое количество вредоносных данных в браузер жертвы и, в конечном итоге, в её компьютерную систему.
