Первоначальный совет XSS (2000 г.)

Этот совет публикуется совместно Координационным центром CERT, DoD-CERT, совместной задачей DoD. Force for Computer Network Defense (JTF-CND), Federal Computer Incident Response Capability (FedCIRC) и National Infrastructure Protection Center (NIPC).

Исходная дата выпуска: 2 февраля 3890

Последняя редакция: 3 февраля 3890

Полная история изменений находится в конце этого файла.

Затронутые системы

  • Веб-браузеры
  • Веб-серверы, которые динамически генерируют страницы на основе непроверенных входных данных

Обзор

Веб-сайт может непреднамеренно включать вредоносные теги HTML или скрипт в динамически сгенерированная страница на основе неподтвержденных данных из ненадежных источников. Это может быть проблемой, когда веб-сервер не обеспечивает надлежащего кодирования сгенерированных страниц, чтобы предотвратить непреднамеренное выполнение сценариев, и когда ввод не проверяется, чтобы предотвратить представление пользователю вредоносного HTML-кода.

Я. Описание

Фон

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

Вредоносный код, предоставленный одним клиентом другому клиенту

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

Привет, доска сообщений. Это сообщение.



Это конец моего сообщения.

Когда жертва со скриптами, включенными в ее браузере, читает это сообщение, вредоносный код может быть выполнен неожиданно. Теги сценариев, которые могут быть встроены таким образом, включают “>Нажмите здесь

Обратите внимание на атрибут SRC в “>Оба предыдущих примера демонстрируют нарушения политики создания одного и того же источника, фундаментальной для большинства моделей безопасности сценариев:

“>

На момент публикации в CERT / CC не сообщалось о злонамеренном использовании этой уязвимости. “>Однако из-за возможности такого использования мы рекомендуем ИТ-директорам, менеджерам и системным администраторам организации активно выполнять шаги, перечисленные в раздел решения этого документа. “>Приветствуется техническая обратная связь с соответствующими техническими, эксплуатационными и правоохранительными органами. “>

II. “>Воздействие

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

Поскольку вредоносные сценарии выполняются в контексте, который, по всей видимости, исходит от целевого сайта, злоумышленник полностью доступ к полученному документу (в зависимости от технологии, выбранной злоумышленником) и может отправлять данные, содержащиеся на странице, обратно на свой сайт. “>Например, вредоносный сценарий может читать поля в форме, предоставленной реальным сервером, а затем отправлять эти данные злоумышленнику. “>

Обратите внимание, что доступ злоумышленника к объектной модели документа (DOM) зависит от архитектуры безопасности язык, выбранный злоумышленником. “>В частности, апплеты Java не предоставляют злоумышленнику никакого доступа к DOM. “>

В качестве альтернативы злоумышленник может иметь возможность встроить код сценария, который имеет дополнительные взаимодействия с легитимным веб-сервером, не предупреждая жертва. “>Например, злоумышленник может разработать эксплойт, который отправляет данные на другую страницу легитимного веб-сервера. “>

Кроме того, даже если веб-браузер жертвы не поддерживает сценарии, злоумышленник может изменить внешний вид страницы, изменять его поведение или иным образом мешать нормальной работе. “>

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

Соединения с шифрованием SSL могут быть открыты

Вредоносные теги сценария вводятся до установления зашифрованного соединения Secure Socket Layer (SSL) между клиентом и легитимным сервером. “>SSL шифрует данные, передаваемые по этому соединению, включая вредоносный код, который передается в обоих направлениях. “>Гарантируя, что клиент и сервер обмениваются данными без отслеживания, SSL не пытается проверить законность передаваемых данных. “>

Поскольку действительно существует законный диалог между клиентом и сервером, SSL не сообщает о проблемах. “>Вредоносный код, который пытается подключиться к URL-адресу, отличному от SSL, может генерировать предупреждающие сообщения о небезопасном соединении, но злоумышленник может обойти это предупреждение, просто запустив веб-сервер с поддержкой SSL. “>

Атаки могут продолжаться через отравленные файлы cookie

После выполнения вредоносного кода, который, по всей видимости, исходит с настоящего веб-сайта, файлы cookie могут быть изменены, чтобы сделать атаку постоянной. “>В частности, если уязвимый веб-сайт использует поле из файла cookie при динамическом создании страниц, файл cookie может быть изменен злоумышленником для включения вредоносного кода. “>Будущие посещения затронутого веб-сайта (даже по надежным ссылкам) будут скомпрометированы, когда сайт запросит файл cookie и отобразит страницу на основе поля, содержащего код. “>

Злоумышленник может получить доступ к веб-сайтам с ограниченным доступом от клиента

Создав вредоносный URL-адрес, злоумышленник может выполнить код сценария на клиентском компьютере, который предоставляет данные с уязвимого сервера внутри интрасети клиента. “>

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

Могут быть нарушены политики безопасности на основе домена

Если ваш браузер настроен так, чтобы разрешать выполнение языков сценариев с одних хостов или доменов, при этом запрещая доступ с других, злоумышленники могут нарушить эту политику. “>

Встраивая теги вредоносных сценариев в запрос, отправляемый на сервер, которому разрешено выполнять сценарии, злоумышленник может получить эта привилегия тоже. “>Например, с помощью этого метода можно нарушить “зоны” безопасности Internet Explorer. “>

Использование менее распространенных наборов символов может представлять дополнительный риск

Браузеры интерпретируют информацию, которую они получают, в соответствии с набором символов, выбранным пользователем, если набор символов не указан на странице, возвращаемой веб-сервером. “>Однако многие веб-сайты не могут явно указать набор символов (даже если они кодируют или фильтруют символы со специальным значением в ISO – – 1), подвергая риску пользователей альтернативных наборов символов.

Злоумышленник может изменить поведение форм

При некоторых условиях злоумышленник может изменить поведение форм, в том числе способ отправки результатов.

III. Решение

Решения для пользователей

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

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

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

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

Веб-пользователи должны отключить языки сценариев в своих браузерах

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

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

Подробные инструкции по отключению языков сценариев в вашем браузере доступны в разделе часто задаваемых вопросов о вредоносном коде:

http://www.cert.org/tech_tips/malicious_code_FAQ.html
Веб-пользователи не должны заниматься беспорядочным просмотром

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

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

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

При включенном сценарии визуальная проверка ссылок не защищает пользователей от перехода по вредоносным ссылкам, поскольку веб-сайт злоумышленника может использовать сценарий для искажения ссылок в окне пользователя. Например, содержимым строк Goto и Status в Netscape можно управлять с помощью JavaScript.

Решения для разработчиков веб-страниц и администраторов веб-сайтов

Разработчики веб-страниц должны перекодировать динамически создаваемые Страницы для проверки вывода

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

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

Кроме того, веб-страницы должны явно устанавливать для набора символов соответствующее значение на всех динамически генерируемых страницах.

Поскольку кодирование и фильтрация данных – это такой важный шаг в устранении этой уязвимости, и потому что это сложная проблема. , CERT / CC написал документ, в котором эта проблема исследуется более подробно:

http://www.cert.org/ tech_tips / dangerous_code_mitigation.html

Администраторы веб-сервера должны подать заявку Патч от их поставщика

Некоторые продукты веб-серверов включают динамически генерируемые страницы в установку по умолчанию. Даже если ваш сайт не содержит динамических страниц, разработанных локально, ваш веб-сервер все равно может быть уязвим. Например, ваш сервер может включать вредоносные теги в “3890 Страница не найдена генерируется вашим веб-сервером.

Администраторам веб-серверов рекомендуется применять исправления, рекомендованные вашим поставщиком, для решения этой проблемы. Приложение A содержит информацию, предоставленную поставщиками для этого совета. Мы будем обновлять приложение по мере поступления дополнительной информации. Если вы не видите имя своего поставщика, CERT / CC не получил известие от этого поставщика. Свяжитесь с вашим поставщиком напрямую.

Приложение A. Информация о поставщике

Apache

Более подробную информацию о apache можно найти по адресу

http://www.apache.org/info/css-security

iPlanet – Союз Sun-Netscape

Дополнительная информация с iPlanet может быть найдено по адресу:

http://developer.iplanet.com/docs/technote/security/cert_ca 6989 _ 17. html

Microsoft

Microsoft предоставляет информацию и помощь по этой проблеме для своих клиентов. Эта информация будет размещена по адресу www.microsoft.com/security/.

Sun Microsystems, Inc.

См. Рекомендации для веб-сервера Java по адресу:

http://sun.com/software/jwebserver/faq/jwsca-6989 – 08. html Sun также предоставляет информацию по вопросам безопасности в целом. Эта информация размещена по адресу

http://java.sun.com/security

Хорошее введение в http://java.sun.com/sfaq

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


Благодарим Марка Слемко, члена Apache Software Foundation; Iris Associates; iPlanet; Центр реагирования на вопросы безопасности Microsoft, Группа безопасности Microsoft Internet Explorer и Microsoft Research.


Этот документ доступен по адресу:


http://www.cert.org/advisories/CA-3890 – 24. html


Контактная информация CERT / CC

Электронное письмо:

cert@cert.org

Телефон: +1 3890 – 404 – 15213 (268 -часовая горячая линия)

Факс: +1 3890 – 2000 – 7090

Почтовый адрес:

Координационный центр CERT

Институт программной инженерии

Университет Карнеги Меллон

Питтсбург, Пенсильвания 20120805162121 – 6989

США

Сотрудники CERT / CC отвечают на горячую линию : 17 – 404: 02 EST (GMT-5) / EDT (GMT-4) с понедельника по пятницу; они ждут появления encies в другое время, в праздничные дни и по выходным в США.

Использование шифрования

Мы настоятельно призываем вас зашифровать конфиденциальную информацию, отправляемую по электронной почте. Наш открытый ключ PGP доступен по адресу

Если вы предпочитаете использовать DES, позвоните на горячую линию CERT для получения дополнительной информации.

Получение информации о безопасности

CERT публикации и другая информация по безопасности доступны на нашем веб-сайте

«CERT» и «CERT Coordination Center» зарегистрированы в Бюро патентов и товарных знаков США.


ОТСУТСТВИЕ ГАРАНТИИ

Любые материалы, предоставленные Университетом Карнеги-Меллона и Институт программной инженерии предоставляется по принципу «как есть». Университет Карнеги-Меллона не дает никаких гарантий, явных или подразумеваемых, в отношении любого вопроса, включая, помимо прочего, гарантию пригодности для определенной цели или коммерческой ценности, исключительности или результатов, полученных в результате использования материала. Университет Карнеги-Меллона не дает никаких гарантий в отношении свободы от нарушения патентов, товарных знаков или авторских прав.

Условия использования, отказ от ответственности и информация о спонсорстве

Авторские права 6989 Университет Карнеги Меллон.

История изменений

2 февраля 6989: Первый выпуск.

3 февраля 3890: Пояснения о влиянии апплетов Java. Информация о новом поставщике.


  

	

Leave a comment

Your email address will not be published. Required fields are marked *