Обновлено: 21 июля 2026
XSS или межсайтовый скриптинг - это коварная уязвимость веб-приложений. Она позволяет киберпреступникам осуществлять внедрение и исполнение некоего скрипта в контексте самого веб-приложения или интернет-страницы, которую просматривает пользователь. Что позволяет сделать XSS:
Иногда злоумышленники используют межсайтовый скриптинг для распространения вредоносного ПО - его «прячут» в коде. Идеальной защиты от XSS-атак, к сожалению, не существует. Однако, разобравшись в структуре подобных уязвимостей можно минимизировать возможность эксплуатации уязвимостей злоумышленниками.
XSS - это не одна конкретная схема, которую хакеры используют для атак, а целый класс уязвимостей. К числу основных разновидностей при классификации относят:
Эта разновидность предполагает, что вредоносный скрипт злоумышленники сохраняют прямо в базе данных приложения или на сервере. В большинстве случаев Stored XSS можно «встретить» там, где у пользователей есть возможность размещать некую информацию (к примеру, текстовую), которая потом отобразится для других пользователей веб-страницы.
Наиболее распространенные примеры - это комментарии, форумы и личные переписки. Если в полях, доступных для редактирования пользователями, не предусмотрена надлежащая фильтрация, то хакер получает возможность добавить вредоносный скрипт прямо в текст своего комментария или сообщения на форуме. Вредоносный код сохранится непосредственно в базе и будет автоматически выполняться в браузере любого пользователя, который прочитает это сообщение или комментарий.
В отличие от отраженных скриптов, хранимый скрипт будет выполнен браузером любого пользователя, который откроет страницу или раздел, где будет выводиться зараженный контент.
Чтобы провести XSS-атаку этого типа, злоумышленник создает запрос или ссылку с фрагментом кода, чтобы сервер этот код «отражал» в ответе на запрос. Пользователь кликает по ссылке или, например, открывает электронное письмо с встроенным URL, и браузер в итоге получает от сервера веб-страницу с «встроенным» опасным или вредоносным скриптом.
В большинстве случаев, чтобы использовать возможности этой разновидности межсайтового скриптинга, хакер должен обеспечить отправку вредоносной ссылки пользователю и мотивировать последнего по ней перейти.
Эта разновидность наименее очевидна и требует от злоумышленников навыков манипуляции с DOM-деревом. В некоторых случаях для реализации атаки не нужно даже взаимодействовать с сервером, а свои действия злоумышленники совершают внутри клиентского JavaScript-кода.
Будет ли у преступника такая возможность - зависит от фильтрации и экранирования на стороне клиента. Если ни того, ни другого нет, то хакер может сконструировать специальный URL (или проще - адрес интернет-ресурса) и внедрить вредоносный скрипт прямо в его параметры. Тогда, выполняя этот скрипт, браузер автоматически запустит вредоносное «дополнение».
Злоумышленники не всегда используют только одну из базовых разновидностей в «чистом виде». Существует ряд гибридных XSS-уязвимостей, в том числе:
Отдельно стоит отметить Self-XSS. Этот тип атаки не относится к XSS с технической точки зрения, потому что код внедряется не через уязвимость. Здесь «слабое звено» - сам пользователь. Киберпреступник уговаривает пользователя вставить вредный скрипт в консоль, обещая некие бонусы, преимущества, разблокировку «секретных возможностей». Часто используется в социальных сетях и на игровых интернет-порталах.
Для злоумышленников не составляет особого труда проверить, присутствует ли в веб-приложении или на сайте уязвимость типа XSS. Вполне достаточно отправить запрос с вредоносным скриптом и понаблюдать, как ответит сервер: позволит ли выполнить вредоносный код на стороне клиента.
Что касается предотвращения и устранения уязвимостей - здесь все обстоит намного сложнее, так как требует тщательного подбора способов безопасной обработки данных. Экранирование на одном из участков кода (в том числе на сервере) проблему не решает и, к сожалению, просто запретить теги <script> - необходимо, но отнюдь не достаточно.
Чтобы эффективно противостоять XSS-атакам, важен комплексный подход с реализацией следующих ключевых моментов:
Кодировка и экранирование данных при выводе должно осуществляться с учетом контекста вывода. В рамках экранирования и энкодинга данных, в частности, требуется предусмотреть преобразование специальных символов в HTML-сущности перед выводом чего бы то ни было в браузер. Также могут помочь современные фреймворки - их шаблоны предусматривают экранирование опасных символов по умолчанию.
Cookies также нуждаются в защите от доступа через скрипт с клиентской стороны. Использование специальных флагов (например, Secure и HttpOnly) даст возможность разрешить передавать данные только в том случае, если используется зашифрованное соединение.
CSP - это эффективный стандарт безопасности, который необходим для ограничения перечня источников загрузки элементов оформления и скриптов при открытии интернет-страницы в браузере. Корректные настройки Content Security Policy позволяют сайтам загружать данные только из доверенных источников, так что вредоносные скрипты при открытии страницы срабатывать не будут. Кроме того, этот стандарт дает возможность блокировать выполнение скриптов, даже если они встроены непосредственно в HTML-код сайта. Тем не менее, CSP является лишь дополнительным слоем защиты, который препятствует эксплуатации XSS и уменьшает ущерб, но не заменяет корректную обработку данных.
Данные, которые сервер получает от сторонних пользователей, должны проходить строгую проверку. Необходимо ограничивать типы и форматы данных, которые пользователи могут размещать.
Это мера, направленная на минимизацию возможного ущерба. Принцип заключается в том, что даже если злоумышленнику удастся внедрить и запустить скрипт, его возможности будут сильно ограничены «урезанными» правами, заданными на уровне приложения или платформы. Это позволяет блокировать выполнение наиболее опасных сценариев (например, критических операций с данными или настройками системы), так как у атакованной учетной записи просто не будет на них полномочий.
Анализ исходного кода на уязвимости должен проводиться как после каждого значимого изменения, так и планово (например, раз в полгода или год, в зависимости от интенсивности изменений). Важно формализовать процедуры безопасной разработки и внедрить автоматизированные средства анализа в процесс разработки и CI/CD, чтобы уязвимости, включая XSS, выявлялись и исправлялись еще до релиза.
Мы интегрируем такие решения на сторону разработки — например, встраиваем PT Application Inspector, позволяющий специалистам по ИБ выявлять и подтверждать уязвимости и недокументированные возможности, а разработчикам повысить эффективность устранения уязвимостей на ранних этапах.
В дополнение к стандартному «набору» также стоит предусмотреть обучение пользователей основам кибергигиены (например, не доверять инструкциям из недоверенных источников и не вставлять в браузерную консоль коды, которые выглядят подозрительно или пришли от неизвестного лица), а также проводить регулярные тестирования на устойчивость к XSS, не забывая о существовании гибридных разновидностей.
Важно помнить, что 100%-ую защищенность от XSS гарантировать невозможно, но комплексный подход и использование эффективных мер безопасности способны значительно усложнить задачу хакерам и мотивировать их искать менее подготовленную и защищенную жертву.
Кейсы
Кейсы
Кейсы
