Что такое XSS атаки и как от них защититься

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

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

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

Основные разновидности межсайтового скриптинга

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

Хранимые / Stored

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

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

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

Отражённые / Reflected

Чтобы провести XSS-атаку этого типа, злоумышленник создает запрос или ссылку с фрагментом кода, чтобы сервер этот код «отражал» в ответе на запрос. Пользователь кликает по ссылке или, например, открывает электронное письмо с встроенным URL, и браузер в итоге получает от сервера веб-страницу с «встроенным» опасным или вредоносным скриптом.

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

Основанные на работе с DOM

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

Будет ли у преступника такая возможность - зависит от фильтрации и экранирования на стороне клиента. Если ни того, ни другого нет, то хакер может сконструировать специальный URL (или проще - адрес интернет-ресурса) и внедрить вредоносный скрипт прямо в его параметры. Тогда, выполняя этот скрипт, браузер автоматически запустит вредоносное «дополнение».

Гибридные

Злоумышленники не всегда используют только одну из базовых разновидностей в «чистом виде». Существует ряд гибридных XSS-уязвимостей, в том числе:

• Polyglot XSS - сложный гибрид, который используют для обхода систем защиты и фильтров повышенной сложности. В таких типах атаки предусмотрена одновременная работа одного и того же нагрузочного кода сразу в нескольких контекстах;
• Blind XSS - «продвинутая» разновидность XSS хранимого типа. Вредоносный скрипт внедряется там, где результат не очевиден «в моменте» с точки зрения киберпреступника (к примеру, в CRM или админ-панель) и срабатывает только в том случае, если уязвимую страницу открыл привилегированный пользователь (например, администратор). Используется, когда необходимо организовать атаку на внутренние системы, добраться до которых извне невозможно или очень трудно.
• Mutated XSS - вредоносный код способен «мутировать» при обработке системой шаблонов или браузером. При первой фильтрации он выглядит безопасным, но может стать вредоносным после DOM-мутации. 

Отдельно стоит отметить Self-XSS. Этот тип атаки не относится к XSS с технической точки зрения, потому что код внедряется не через уязвимость. Здесь «слабое звено» - сам пользователь. Киберпреступник уговаривает пользователя вставить вредный скрипт в консоль, обещая некие бонусы, преимущества, разблокировку «секретных возможностей». Часто используется в социальных сетях и на игровых интернет-порталах.

Защита от XSS: эффективные меры и комплексный подход

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

Что касается предотвращения и устранения уязвимостей - здесь все обстоит намного сложнее, так как требует тщательного подбора способов безопасной обработки данных. Экранирование на одном из участков кода (в том числе на сервере) проблему не решает и, к сожалению, просто запретить теги <script> - необходимо, но отнюдь не достаточно.

Чтобы эффективно противостоять XSS-атакам, важен комплексный подход с реализацией следующих ключевых моментов:

Контекстно-зависимое кодирование 

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

Защита Cookies

Cookies также нуждаются в защите от доступа через скрипт с клиентской стороны. Использование специальных флагов (например, Secure и HttpOnly) даст возможность разрешить передавать данные только в том случае, если используется зашифрованное соединение.

CSP (Content Security Policy)

CSP - это эффективный стандарт безопасности, который необходим для ограничения перечня источников загрузки элементов оформления и скриптов при открытии интернет-страницы в браузере. Корректные настройки Content Security Policy позволяют сайтам загружать данные только из доверенных источников, так что вредоносные скрипты при открытии страницы срабатывать не будут. Кроме того, этот стандарт дает возможность блокировать выполнение скриптов, даже если они встроены непосредственно в HTML-код сайта. Тем не менее, CSP является лишь дополнительным слоем защиты, который препятствует эксплуатации XSS и уменьшает ущерб, но не заменяет корректную обработку данных.

Валидация

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

Ограничение прав пользователей 

Это мера, направленная на минимизацию возможного ущерба. Принцип заключается в том, что даже если злоумышленнику удастся внедрить и запустить скрипт, его возможности будут сильно ограничены «урезанными» правами, заданными на уровне приложения или платформы. Это позволяет блокировать выполнение наиболее опасных сценариев (например, критических операций с данными или настройками системы), так как у атакованной учетной записи просто не будет на них полномочий.

Анализ кода на уязвимости

Анализ исходного кода на уязвимости должен проводиться как после каждого значимого изменения, так и планово (например, раз в полгода или год, в зависимости от интенсивности изменений). Важно формализовать процедуры безопасной разработки и внедрить автоматизированные средства анализа в процесс разработки и CI/CD, чтобы уязвимости, включая XSS, выявлялись и исправлялись еще до релиза.