Compartir a través de

Безопасность IE8: изменения в Beta 2

  • Artículo

Теперь, когда состоялся выпуск версии Beta 2, хотелось бы рассказать вам о тех изменениях в системе безопасности IE8, которые команда разработчиков внесла в него.

Ограничение document.domain

Изначально свойство document.domain возвращает полное имя домена сервера, с которого была загружена страница. Это свойство было назначено суффиксу домена, чтобы сделать возможным общий доступ к странице через фреймы от различных имен компьютеров. Например, два фрейма, запущенные на app1.example.com и app2.example.com могут конфликтовать друг с другом, если оба они установят в document.domain значение общего домена example.com. Фрейм может не устанавливать в значение домена, прописанное в свойствах, домен верхнего уровня, в отличие от различных доменных суффиксов. Например, app1.example.com не может установить свойством домена значение .com или microsoft.com. В HTML5 формализуется алгоритм, используемый для определения возможности установки данного значения свойства домена, причем особым требованием являет обязательное совпадение назначенного значения с суффиксом текущего значения.

В Internet Explorer 7 использовался бы следующий набор запросов:

Код:

// Первоначальный document.domain установлен в app1.example.com

document.domain = "app1.example.com"; // 1. Свойство domain установлено в значение по умолчанию

document.domain = "example.com"; // 2. "Сокращенный" домен

document.domain = "app1.example.com"; // 3. "Растянутый" домен

В Internet Explorer 8 и других обозревателях третий оператор присвоения вызовет исключение, потому что app1.example.com – это не суффикс текущего значения, example.com. Выглядит все просто, правда после сокращения document.domain вы не сможете «растянуть» его.

Веб-приложения, которым нужно работать с данными других доменов, могут использовать API postMessage() или XDomainRequest вместо того, чтобы редактировать свойство document.domain.

Ограничения переназначения фреймов

HTML5 также формулирует условия, при которых одному фрейму разрешается использовать параметр targetname запроса windows.open() для перехода к другому фрейму или окну.

Эти правила призваны помочь устранить уязвимость внедрения окна. При injection-атаке вредоносный веб-сайт в одном фрейме обозревателя пытается «украсть» фрейм или всплывающее окно, принадлежащее доверенному веб-сайту.

Например, рассмотрим случай, когда https://contoso.com открывает всплывающее окно с именем helpPage.

window.open("helpTopic.htm", "helpPage", "height=200,width=400");

В другом окне https://evil.example.com пытается «украсть» это окно следующим образом:

window.open("spoof.htm", "helpPage", "height=200,width=400");

Вместо того, чтобы переходить к окну helpPage, принадлежащему Contoso.com, spoof.htm открывается в новом окне обозревателя. В связи с тем, что Internet Explorer 7 и 8 отображают адресную строку в любом окне, это новое ограничение делает подобные атаки еще менее убедительными.

MIME-Handling: обход функции MIME-sniffing

Как уже обсуждалось в пятой части этой серии блогов, функция MIME-sniffing в Internet Explorer может вызывать проблемы безопасности для серверов, на которых хранится непроверенный контент. Тогда мы анонсировали новый атрибут Content-Type (носящий название «authoritative»), который может быть использован для отключения MIME-sniffing для отдельных response-заголовков HTTP.

За прошедшие два месяца мы получили множество отзывов от сообщества, в которых говорилось о том, что использование нового атрибута в заголовке Content-Type создавало множество проблем при развертывании для операторов серверов. В итоге мы преобразовали эту опцию в полноценный response-заголовок HTTP. Отправка нового response-заголовка X-Content-Type-Options со значением nosniff удержит Internet Explorer от активации MIME-sniffing вне зависимости от заявленного типа контента.

Для примера привожу следующий response-заголовок HTTP:

Код:

HTTP/1.1 200 OK

Content-Length: 108

Date: Thu, 26 Jun 2008 22:06:28 GMT

Content-Type: text/plain;

X-Content-Type-Options: nosniff

<html>

<body bgcolor="#AA0000">

This page renders as HTML source code (text) in IE8.

</body>

</html>

В IE7 этот текст интерпретировался как HTML:

clip_image002

В IE8 эта страница визуализируется в таком виде:

clip_image004

Сайты, хранящие непроверенный контент, могут использовать заголовок X-Content-Type-Options: nosniff, чтобы гарантировать, что файлы text/plain будут использованы правильно.

Сокращение области атаки XSS: CSS Expressions отключают IE8 Standards Mode

CSS Expressions (или динамические свойства -- Dynamic Properties) являются частным расширением для CSS, утилизирующем высокую производительность. CSS Expressions также часто используются хакерами для обхода серверных XSS-фильтров.

В Beta 2 CSS Expressions не поддерживаются в режиме Standards Mode. Они все еще работают в режимах Strict и Quirks IE7 для обеспечения обратной совместимости. Хотя XSS-фильтр IE8 может блокировать попытки отразить CSS Expressions как часть XSS-атаки, его блокирование в режиме IE8 Standards Mode приносит значительные выгоды в производительности, улучшает совместимость со стандартами, а также сокращает область действия для injection-атак.

Подробная информация о IE8 XSS Filter

Дэвид Росс, архитектор IE8 XSS Filter, опубликовал в блоге Secure Windows Initiative техническую статью, в которой содержатся детали об архитектуре и реализации XSS Filter. Если вам интересно, как работает XSS Filter, вы можете обратиться к ней.

Эрик Лоуренс (Eric Lawrence)

Программный менеджер Internet Explorer Security

Comments

  • Anonymous
    July 09, 2010
    This blog has been created to share useful information. Thanks and greetings!