Наравне DDoS на слуху у многих владельцев онлайн-бизнеса такой термин, как XSS атака, где аббревиатура указывает на тип уязвимости (Cross-site-scripting), который можно встретить в различных веб-приложениях, интернет-площадках. Вирусный скрипт (в некоторых источниках - эксплойт) внедряется в веб-страницы, чтобы через слабые места ресурсов осуществить кражу логинов/паролей, cookies, данных банковских карт или подмочить репутацию владельца онлайн-бизнеса.

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

Что такое XSS-атака

X-Site Scripting – межсайтовый скриптинг – один из трех известных видов веб-атак. Заключается во включении вирусного кода в тело страницы онлайн-проекта, приложения. Главная угроза состоит в том, что большинство sites содержит определенную информацию о посетителях при наличии уязвимых мест. Злоумышленники пользуются последними, чтобы получить доступ к чувствительным данным, например, платежным картам, паспортным данным, гаджетам пользователей.

Что такое XSS-атака.
Image by Freepik.

Принцип работы межсайтового скриптинга

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

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

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

Виды XSS-уязвимостей

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

На текущий период выделяют несколько видов XSS-уязвимостей.

Stored XSS (Хранимая XSS)

Бреши возникают при взломе доступа к серверу, сохранении там вредоносного скрипта. Он начнет проявлять активность всякий раз, когда гость зайдет на «больную» страницу.

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

Reflected XSS (Отраженная XSS)

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

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

DOM-Based XSS (XSS на основе DOM)

В данном случае для внедрения эксплойта недобросовестными лицам используются Document Object Model. Данный интерфейс дает программам, сценариям доступ к содержанию веб-страниц, XML-документам. Это позволяет управлять оформлением, контентом, структурой. XSS-бреши на основе объектной модели документа могут быть и Stored XSS, и Reflected XSS. Основная особенность Dom-Bases XSS – изменение веб-страницы, приложения не происходит, изменяется их отображение в пользовательском браузере.

Каким образом злоумышленник внедряет вредоносный код

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

Для хакерского скриптинга используются следующие лазейки в защите ресурса, приложения:

  • Ошибки, сделанные в браузере. Речь идет о программах, используемых пользователями. Распространенный пример: реализация сценария посредством SVG, при которой появляется возможность не принимать во внимание правило ограниченного домена. Это грубая, заметная ошибка разработчиков, поэтому быстро проявляется и устраняется. Если в программе «поселились» более «утонченные», малозаметные уязвимости, то рекомендуется не ждать очередного апдейта браузера, а установить эффективную защиту самого проекта.
  • Проблемы с экранированием. Пока браузеры не научились дифференцировать обыкновенный текст от кода. Для распознавания и реализации команд последнего необходима разметка тегами: Java-скрипта размещаются между <script>, CSS – между CSS.

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

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

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

  • Замена кодировки в заглавии страницы. Определение кодировок происходит в ходе обработки веба. Она находится в метке <meta>, если <title> расположен до нее, то браузер начинает работать с заголовком, после обращает внимание на кодировку. У взломщика появляется шанс обойтись без фильтрации символов <>, “” и поместить в title вредоносный скрипт, созданный в формате UTF-7.
  • Межсайтовый скриптинг при SQL-инъекции – смешанный способ атаки с привлечением базы данных ресурса. В страницу базы данных посредством SQL-инъекции внедряется созданный хакером код. Если сайт не защищен экранами при использовании БД, то при использовании «больной» строки, вредоносное содержание переходит в браузер посетителя.

Каковы последствия от XSS-атаки

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

  • Хищение данных пользователей. Площадки с авторизацией понимают, какой гость авторизирован с помощью куки-файла. Он виден самому посетителю и любому JavaScript-коду его браузера. Перехватив cookie добропорядочного гражданина, скрипт пересылает его на удаленный сервер взломщика. Теперь можно похищать чувствительную информацию, получать доступ к переписке, использовать чужой аккаунт для спам-рассылки, воспользоваться бесплатно оплаченными кем-то курсами.
  • Получение доступа к управлению проектом. Это произойдет в том случае, если удастся завладеть правами админа. Возможность хозяйничать на чужой площадке позволит получить массив данных по авторизации пользователей, инициировать сбой ресурса, испортить дизайн, разместить компромат, противозаконный материал, заполучить секретные документы.

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

Защита от XSS-атак

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

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

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

Когда все лазейки выявлены, рекомендуется заняться защитой от XSS-атак:

  • Сделать настройку фильтров, экранизации параметров входа, вводимых через формы авторизации и т.д.;
  • Отрегулировать автозамену специальных символов, чтобы разграничить обычный текст от кода;
  • Поместить на страницах кодировку перед полями посетителей;
  • C помощью протокола SSL, атрибута HttpOnly настроить ограничения домена, возможностей приема куки-файлов;
  • Систематически проверять приложения, проект на предмет уязвимости;
  • Использовать политику SOP для определения эксплойтов, которым предоставляется доступ к информации. Иными словами – с каких площадок им разрешено получать данные посетителей.
  • Создать посредством Content Security Policy список веб-источников, которые разрешены для загрузок контента;
  • Постоянно делать апдейт браузера.

Заключение

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