Очередная и итоговая статья из цикла "Безопасность Internet Explorer 8". В этой статье мы объединим информацию из всех предыдущих статей и попробуем оценить, насколько выросла безопасность Internet Explorer 8 по сравнению с предыдущими релиза браузера.
Привет, я Эрик Лоуренс (Eric Lawrence), программный менеджер по безопасности Internet Explorer. Не так давно мы публиковали статью о наших принципах по разработке надежного браузера, а сегодня я имею честь подвести итог нашей работе, которую мы проделали с целью увеличить безопасность Internet Explorer 8.
Как можно догадаться по длине статьи, мы провели большую работу. Как обычный пользователь при обновлении до IE8 вы сможете лучше защитить себя и свои личные данные при работе в Интернете. Как администратор домена вы сможете использовать групповые политики и IEAK, чтобы повысить безопасность вашей сети. Как разработчик на основе этих функций вы сможете создать новые функции, которые помогут обезопасить ваше приложение и пользователей.
Когда мы планировали Internet Explorer 8, наша команда по безопасности внимательно изучила самые распространенные атаки и тенденции, на которых атакующие в будущем сконцентрируют свое внимание. Пока мы создавали новые функции безопасности, мы много работали над тем, чтобы убедится, что такие функции IE8, как Activities и Web Slices не увеличат поверхность для атаки. Мы классифицировали все угрозы в три основные категории: уязвимости веб-приложений, уязвимости браузера и дополнений, угрозы социального инжинеринга. Для каждого класса угроз мы разработали свой набор преград, призванных обеспечить глубокую защиту от эксплойтов.
Защита веб-приложений
- Защита от межсайтового скриптинга (XSS)
За последние несколько лет атаки с использованием межсайтового скриптинга по своему количеству превысили атаки с использованием переполнения буфера и стали самым распространенным классом программных уязвимостей. XSS-атаки используют уязвимости в веб-приложениях, чтобы украсть cookie-файлы или другие данные, для искажения страниц, кражи конфиденциальных данных и иной информации.IE8 помогает уменьшить угрозу от XSS, блокируя наиболее часто используемые формы XSS-атак, называемые атаками отражения. XSS-фильтр IE8 является эвристическим смягчителем, который обеззараживает внедренные скрипты, предотвращая их исполнение. Больше вы можете прочитать в статье Безопасность IE8: XSS-фильтр.
XSS-фильтр предоставляет хорошую защиту против эксплойтов, но так как данная функция доступна только в IE8 важно, чтобы веб-разработчики предоставляли дополнительную глубокую защиту и работали над избавлением от XSS-уязвимостей на своих сайтах. Предотвратить XSS-атаки на стороне сервера намного легче, чем через браузер. Большинство платформ веб-технологий предоставляют одну или больше технологий обезвреживания - разработчики, использующие ASP.NET, используют Microsoft Anti-Cross Site Scripting Library. Для дополнительного уменьшения угрозы кражи cookie с помощью XSS, уязвимые cookies, особенно те, которые используются для аутентификации, должны быть защищены с помощью атрибута HttpOnly.
- Безопасные mashup
В то время как XSS-фильтр помогает сократить количество скриптовых атак отражения при переходе между двумя серверами в мире Web 2.0, все чаще сайты создаются с использованием клиентских mashup-технологий. Многие mashup созданы небезопасными, полагающимися на техники SCRIPT SRC, которые просто внедряют скрипты внешней стороны в mashup-страницу, предоставляя третьей стороне полный доступ к DOM и cookie типа, отличного от HttpOnly.Чтобы помочь разработчикам создавать более безопасные mashup-сайты для Internet Explorer 8, мы представили поддержку обмена сообщениями между документами из HTML 5, которая позволяет IFRAME реализовывать более безопасную связь, при этом реализуя изоляцию DOM. Мы также представили объект XDomainRequest, чтобы разрешить безопасную передачу "публичных" данных между доменами в сети.
Хотя Cross-Document-Messaging и XDomainRequest помогают обезопасить mashup, критическая угроза все равно остается. Использование объекта, строковых данных, полученных из стороннего фрейма или сервера, может содержать в себе скрипт. Если вызывающая сторона вслепую включает строку в свой DOM, то произойдет атака внедрения скрипта. Поэтому мы рады представить две технологии, которые могут быть использованы в комплекте с механизмами по обмену сообщениями между доменами смягчения атак внедрения скриптов.
- Безопасные mashup: обезвреживание HTML
В IE8 представлен новый метод к объекту окна под названием toStaticHTML. Когда строка HTML обращается к данной функции, любая конструкция запускаемого скрипта удаляется до того, как строка будет возвращена. По сути эта технология основана на той же технологии, что и Microsoft Anti-Cross Site Scripting Library, о которой говорилось раньше.Итак, например, вы можете использовать toStaticHTML, чтобы удостоверится, что HTML-код, полученный от вызова postMessage, не может извлечь скрипт, но может использовать преимущества базового форматирования.
Код:document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}Вызов
Код:window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");возвратит
Код:This is some <b>HTML</b> with embedded script following... ! - Безопасные mashup: обезвреживание JSON
JavaScript Object Notation (JSON) - это текстовый формат обмена JavaScript-объектами, который часто используется для передачи данных между компонентами mashup. К сожалению, многие mashup используют JSON небезопасно, полагаясь на JavaScript-метод [url=http://msdn.microsoft.com/en-us/library/12k71sw7(VS.85).aspx]eval[/url] для восстановления JSON-строчек обратно в JavaScript объектах, потенциально запуская функцию скрипта в процессе. Сознательные в безопасности разработчики вместо этого используют парсер JSON, чтобы убедится, что JSON объекты не содержат исполняемый скрипт, но за это приходится платить производительностью.В Internet Explorer 8 использует ECMAScript 3.1 для обработки функций JSON, который использует API json2.js от Дугласа Крокфорда (Douglas Crockford). Метод JSON.stringify принимает скриптовый объект и возвращает строку JSON, тогда как метод JSON.parse получает строку и безопасно конвертирует ее в JavaScript-объект. Новые методы JSON основаны на том же коде, что и в самом скриптовом движке, и, таким образом, имеет значительную лучшую производительность по сравнению с другими реализациями. Если результатирующий объект содержит строчки, граничащие с инъекциями в DOM, то ранее описанная функция toStaticHTML может быть использована для предотвращения внедрения скрипта.
Следующий пример использует обезвреживание JSON и HTML для предотвращения внедрения скрипта:
Код:<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
var xdr1 = new XDomainRequest();
xdr1.onload = function(){
var objWeather = JSON.parse(xdr1.responseText);
var oSpan = window.document.getElementById("spnWeather");
oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
+ objWeather.Weather.Forecast.Tonight + "</b> in <u>"
+ objWeather.Weather.City+ "</u>.");
};
xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>даже если вредоносная служба погоды даст вредоносный ответ:
Код:HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
"Today": "Sunny",
"Tonight": "<script defer>alert('bang!')</script>Dark",
"Tomorrow": "Sunny"
}
}} - Обработка изменений MIME
Каждый тип файла, передаваемый с сервера, имеет свой тип MIME, который также называют тип содержимого (от англ. content-type), который описывает природу содержимого (изображение, текст, приложение и т.д.). Из соображений совместимости в Internet Explorer есть функция сниффинга MIME, которая пытается определить тип содержимого для каждого скачанного ресурса. Иногда Internet Explorer сообщает, что тип MIME отличается от того, о котором сообщил сервер. Например, если Internet Explorer обнаружит HTML-содержимое в файле в HTTP-заголовке, которого будет строка Content-Type: text/plain, то IE сообщит, что этот файл должен быть визуализирован как HTML. Так как в сети есть множество устаревших серверов, которые все файлы помечают как text/plain, сниффинг MIME крайне важен для совместимости.К сожалению, сниффинг MIME может привести к проблемам с безопасностью у серверов. Рассмотрим, например, случай с сайтом, который является хостингом для изображений, загруженных анонимными пользователями. Атакующий может загрузить специально созданный JPEG-файл, который содержит скрипт, а потом послать ссылку доверчивой жертве. Когда жертва посетит сервер, вредоносный файл будет загружен, скрипт обнаружен и может быть запущен в контексте самого сайта. После чего скрипт может украсть cookie, создать вредоносную страницу, и т.д.
Чтобы бороться с данной проблемой, мы сделали множество изменений в коде обработчика MIME-типов в Internet Explorer 8.
- Обработка MIME типов: ограничитель загрузки
Во-первых, IE8 предотвращает изменение файлов с типом контента image/* в HTML/Script. Даже если файл содержит скрипт и сервер сообщает, что это изображение, IE не запустит встроенный скрипт. Это изменение - угроза вектору атаки с помощью изображений, при этом без каких-либо изменений на стороне сервера. Мы могли сделать данное изменение с минимальным влиянием на совместимость, так как серверы редко используют специальный HTML-код или скрипты с типом контента image/*. - Обработка MIME: уклонение от сниффинга
Кроме того мы дали веб-приложениям возможность избегать сниффинга MIME-типов. Отправка нового заголовка authoritative=true в HTTP заголовке типа контента предотвращает сниффинг MIME, несмотря на заявленный тип контента.Для примера рассмотрим следующий HTTP-заголовок:
Код:HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>В IE7 текст будет представлен как HTML:
В IE8 текст будет отображаться как чистый текст:
Сайты, которые хостят небезопасный контент могут использовать атрибут authoritative, чтобы убедится, что сниффинг text/plain файлов не покажет, что это какой-то другой тип контента.
- Усиление безопасности
Наконец, для сайтов, которые вынуждены работать с недоверенными HTML-файлами, мы представили механизм, который поможет сохранить безопасность сайта. Если новый заголовок X-Download-Options будет присутствовать со значением noopen, пользователь не сможет открыть файл, скачивая его напрямую, вместо этого его необходимо будет сначала сохранить локально. Когда файл будет открыт позже, он больше не будет открываться в контексте безопасности вашего сайта, что поможет избежать инъекции скрипта.Код:HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
Использование этих новых техник позволит создавать более безопасные веб-приложения.
Локальная защита браузера
И хотя атаки против веб-приложений становятся все более частыми, атакующие всегда заинтересованы во взломе локального компьютера. Чтобы позволить браузеру эффективно использовать политики безопасности для защиты веб-приложений, персональной информации и локальных ресурсов, необходимо предотвращать атаки против браузера. В Internet Explorer 7 были сделаны большие инвестиции в данную область, которые включают в себя защищенный режим, ActiveX Opt-in и Zone Lockdowns. В ответ на укрепление самого браузера, атакующие фокусируются на атаках дополнений.
В Internet Explorer 8 мы усилили безопасность дополнений, сократив поверхность для атаки и улучшив удобство работы разработчиков и пользователей.
- Безопасность дополнений
В данном блоге мы уже публиковали статью о технологии защиты памяти DEP (NX), которая по умолчанию включена в IE8, работающем в Windows Server 2008, Windows Vista SP1 и Windows XP SP3. DEP/NX позволяет изолировать атаки, предотвращая запуск кода из области памяти, которая маркирована как неисполняемая. DEP/NX в комбинации с другими технологиями, как, к примеру, Address Space Layout Randomization (ASLR), усложняя атакующим выполнение определенных атак, связанных с уязвимостями в системе памяти, например, переполнения буфера. Оба типа защиты работают и с Internet Explorer и дополнениями к нему. Дополнительную информацию вы можете прочитать здесь: Безопасность IE8: технология защиты памяти DEP (NX).В данной статье Мэтт Кроули (Matt Crowley) описал улучшения в работе с ActiveX в IE8 и резюмировал существующие связанные с ActiveX функции безопасности, которые поддерживаются с предыдущих версий браузера. Среди ключевых изменений, которые были сделаны в IE8, есть Per-Site ActiveX - защитный механизм, который помогает избежать вредоносную перенастройку элементов управления. IE8 также поддерживает установку элементов управления ActiveX стандартным пользователем. Полный список изменений вы можете прочитать в статье Безопасность IE8: изменения в работе ActiveX. Если вы разрабатываете элементы управления ActiveX, то вы можете защитить своих пользователей путем, описанным в статье Best Practices for ActiveX controls.
- Защищенный режим
Представленный в IE7 в Windows Vista защищенный режим помогает уменьшить важность потоков Internet Explorer и запущенных в нем расширений, помогая предотвратить фоновую установку вредоносного кода, даже если ПО уязвимо. Для Internet Explorer 8 мы сделали множество улучшений в API безопасного режима, чтобы облегчить разработчикам дополнений контроль и взаимодействие с браузерами, запущенными в безопасном режиме. Об этих улучшениях вы можете прочитать в Improved Protected Mode API Whitepaper.Для улучшения производительности и совместимости приложений по умолчанию безопасный режим в IE8 выключен, когда браузер работает в зоне локальной сети. Раньше по умолчанию он был включен из-за некоторых причин, связанных с удобством: при входе или выходе из защищенного режима требовалось перезапускать браузер:
Архитектура Internet Explorer 8 под названием Loosely Coupled позволяет иметь вкладки, запущенные и в защищенном и в обычном режиме в рамках одного окна браузера, что позволяет убрать это раздражающее в работе окно. Конечно, пользователи IE8 и администраторы доменов могут при необходимости включить безопасный режим и для режима работы в локльной сети.
- Запрос протоколов приложений
Обработчик протоколов приложений позволяет сторонним приложениям, таким как плееры потокового мультимедиа и приложения для интернет-телефонии, быть запущенными прямо из браузера или любого другого Windows-приложения. К сожалению, она предоставляет достаточно большую поверхность для атаки, так как некоторые приложения, которые зарегистрированы как обработчики приложений, могут содержать уязвимости, которые в свою очередь могут быть использованы недоверенным контентом из Интернета.Чтобы убедиться в том, что пользователь знает о потенциальной угрозе, теперь Internet Explorer 8 будет спрашивать пользователя перед тем, как запускать протоколы приложений:
Чтобы предоставить глубокую защиту, разработчики протоколов приложений должны следовать практикам и рекомендациям, описанным на MSDN.
- Контроль загрузки файла
Исторически так сложилось, что HTML-элемент управления загрузкой файла (<input type=file>) был источником множества сообщений о нераскрытых ранее уязвимостях. Чтобы решить эту проблему, в поведение данного элемента управления было внесено два изменения.Чтобы блокировать атаки, которые используют перехват клавиатурных нажатий, данный элемент теперь имеет атрибут "только для чтения". Пользователь должен четко с помощью просмотрщика файлов выбрать нужный для загрузки файл.
Кроме того, для Интернет-зоны опция "включать адрес локальной папки при загрузке на сервер" теперь выключена. Это изменение предотвращает утечку потенциально чувствительной информации локальной файловой системы в Интернет. Например, вместо того, чтобы сообщать серверу адрес C:\users\ericlaw\documents\secret\image.png Internet Explorer 8 теперь будет сообщать только имя файла image.png.
Защита от социальной инженерии
Так как защита браузера за последние несколько лет была улучшена, Интернет-мошенники все больше полагаются на социальную инженерию для атаки доверчивых пользователей. Вместо того, чтобы атаковать все крепнущие крепостные стены, атакующие все чаще посещают парадный вход и требуют, чтобы пользователи им доверяли.
В Internet Explorer 8 мы представили некоторые решения, которые помогут пользователю избежать кражи информации на базе представленной информации, собранной с сайта и центров сертификации.
- Изменения в адресной строке
Подсветка домена - новая функция, представленная в IE8 B1, призванная помочь пользователям легче интерпретировать URL-ссылки. Так как доменное имя - наиболее важный идентификатор безопасности в ссылке, то оно выделено черным цветом, тогда как текст ссылки, созданной и контролируемой сайтом, типа строчки запроса и путь, выделены серым цветом.При сочетании с другими технологиями, типа расширенных сертификатов SSL (от англ. Extended Validation SSL - EV SSL) адресная строка Internet Explorer 8 помогает пользователям убедиться, что они предоставляют личную информацию только тому сайту, которому доверяют.
- Фильтр SmartScreen
В Internet Explorer 7 мы ввели фишинговый фильтр - динамическую функцию безопасности, разработанную, чтобы предупреждать пользователей, когда они пытаются зайти на сайт, который известен как фишинговый. Для Internet Explorer 8 на основе успеха функции анти-фишинга, которая блокирует миллионы фишинговых атак каждую неделю, разработали фильтр SmartScreen. Этот фильтр идет намного дальше, чем анти-фишинговый фильтр в деле блокирования сайтов, которые известны как распространяющие вредоносное и злонамеренное ПО, которое пытается атаковать ваш компьютер или украсть ваши данные. SmartScreen работает в комплекте с другими технологиями, типа Windows Defender и Windows Live OneCare, чтобы предоставить всестороннюю защиту от вредоносного ПО.Дополнительную информацию о SmartScreen вы можете прочитать в статье Безопасность IE8: фильтр SmartScreen.
Заключение
Безопасность - основная характеристика надежной работы в сети и Internet Explorer 8 включает в себя множество серьезных улучшений для развития безопасности ландшафта веб-безопасности. И хотя плохие парни никогда не сдаются, команда IE усердно работает над тем, чтобы затруднить их работу, защитив своих пользователей за счет предоставления новых способов защиты.
Читайте наш блог и вы узнаете об изменениях в системе защиты персональной информации, надежности и практике деловых отношений для создания надежного браузинга.