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

09.09.2008 09:10 | Dazila

10368

- T

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

Ограничение document.domain
Изначально свойство document.domain возвращает полное имя домена сервера, с которого была загружена страница. Это свойство было назначено суффиксу домена, чтобы сделать возможным общий доступ к странице через фреймы от различных имен компьютеров. Например, два фрейма, запущенные на app1.example.com и app2.example.com могут конфликтовать друг с другом, если они оба установят в их document.domain значение их общего домена example.com. Фрейм может не устанавливать в значение домена, прописанное в свойствах, домен верхнего уровня, в отличие от различных доменных суффиксов. Например, app1.example.com не может установить свойством домена значение .com или microsoft.com. В HTML5 формализуется алгоритм [url] http://www.w3.org/html/wg/html5/#domain [/url], используемый для определения возможности установки данного значения свойства домена, причем особым требованием являет обязательное совпадение назначенного значения с суффиксом текущего значения.

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

// initial document.domain is app1.example.com 

document.domain = "app1.example.com";  // 1. Domain property set to default value 

document.domain = "example.com";        // 2. "Loosen" domain 

document.domain = "app1.example.com";          // 3. "Tighten" domain

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

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

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

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

Например, рассмотрим случай, когда http://contoso.com открывает всплывающее окно с именем helpPage.
window.open("helpTopic.htm", "helpPage", "height=200,width=400");

В другом окне http://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:

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

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

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

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

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

Эрик Лоуренс (Eric Lawrence)
Программный менеджер Internet Explorer Security

Источник: http://blogs.msdn.com/ie
Перевод: Dazila

По теме

Акции MSFT

420.55 0.00

Акции торгуются с 17:30 до 00:00 по Москве

Что почитать