Безопасность в IE8

Тяжела жизнь простого ишака, то и дело появляются сообщения о найденных уязвимостях в этом браузере. Да и не мудрено, тысячи, а то и десятки тысяч шаловливых ручонок ежедневно его мучают, чтобы найти новые дыры. Мелкософтовцы (кому неприятно название «мелкософт» заменяйте, пожалуйста, на Майкрософт) не падают духом, оперативно (и не очень) закрывают бреши, все повторяется снова и снова. В один прекрасный момент в недрах корпорации рождается идея выпустить очередную версию этого «самого популярного» браузера. Еще быстрее, еще функциональнее и, конечно же, еще безопасней. Ходят слухи, что, ко всему прочему, будут соблюдаться веб-стандарты, и даже тест ACID2 пройден успешно. Но, мне интересно другое: безопасность нового ишака. На днях представители мелкософта гордо заявили о следующих фичах:

— Cross-Site-Scripting Defenses
— Safer Mashups (HTML and JSON Sanitization)
— MIME-Handling Changes (Restrict Upsniff and Sniffing Opt-Out)
— Add-on Security
— Protected Mode
— Application Protocol Prompt
— File Upload Control
— Social Engineering Defenses

Итак, начнем…

1. Cross-Site-Scripting Defenses
XSS (да, именно такая аббревиатура у межсайтого скриптинга, так как CSS занят каскадной таблицей стилей) стал уязвимостью номер один за последние годы. Статистика от NGS за 2007 год неутешительна:
— Broken authentication 67%
— Broken access controls 78%
— SQL injection 36%
— Cross-site scripting 91%
— Information leakage 81%

91% исследуемых веб-приложений оказались уязвимы для XSS. XSS по сути является разновидностью Injection атак (внедрение опасного кода). На эту тему написано много статей, даже больших и умных книг, проблема действительно серьезная. (посмотреть про XSS на www.virtualforge.de/vmovie.php — чудесная флешка, красиво и доходчиво, правда, на английском). Везде, где реализован пользовательский ввод, существует опасность XSS. Все дело в том, что если ввод не фильтруется, то достаточно оставить сценарий скрипта на странице (например, форума, или того же хабра), и этот скрипт автоматически будет выполняться на браузере всех, кто посмотрит данную страницу. Хабру это должно быть знакомо :)
А на IE8 реализован компонент XSS Filter, который анализирует все request и response, выявляет XSS и показывает пользователю красивое окошко, уведомляя его о том, что он спас тебя, модифицировал страничку и предотвратил XSS. Тут конечно встает 2 проблемы: как не заблокировать не XSS, и не накосячить в этом фильтре, чтобы другой запрос в свою очередь не скомпрометировал этот фильтр. Проверка временем покажет. Также мелкософтовцы предусмотрели возможность отключения этого фильтра, передаваемым через http заголовок параметром X-XSS-Protection: 0. Таким образом, компании, которые беспокоятся за то, чтобы их сайт не был «случайно» заблокирован этим фильтром, могут решить свою проблему.
Подробно можно прочитать тут (eng): blogs.msdn.com/ie/archive/2008/07/01/ie8-security-part-iv-the-xss-filter.aspx

2. Safer Mashups (HTML and JSON Sanitization)
Представьте себе ресурс, который является контейнером для других ресурсов, создавая свой контент на основании других страниц. Короче машап  Можно делать машап по разному, например, просто используя SCRIPT SRC. В этом случае, никто не помешает «заинтересованным» лицам получить доступ к Document Object Model. Надо, видимо, как-то изолировать все это дело. Инженеры IE8 реализовали поддержку HTML5 cross-document messaging, чтобы IFRAME’ы могли взаимодействовать более безопасно, благодаря DOM изоляции. Также введен XDomainRequest, чтобы получать открытые (public) данные через домены. Но даже в этом случае опасность остается – можно запихнуть строку скрипта в свой DOM, все это замашапится и выполнится.
IE8 предлагает новый метод для объекта window – toStaticHTML (строка, переданная данному методу проверяется на наличие скрипта, и если он там есть, то скрипт удаляется, и на выходе строка не будет содержать скрипта. Пример:
document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}
Передавая в toStaticHTML строку “This is some HTML with embedded script following… !", на выходе получим
This is some HTML with embedded script following…!
Примерно тоже самое и с JSON объектами, проверяется содержат ли они исполняемый скрипт. Но это уже где-то было ;) Чем же удивил Мелкософт – производительностью. Так это или нет, проверить мне не удасться :)

3. MIME-Handling Changes (Restrict Upsniff and Sniffing Opt-Out)
Каждый передаваемый веб-сервером тип файла ассоциирован с MIME типом (так же называют content-type). Каждый тип файлов браузер обрабатывает по разному. Для совместимости IE имеет свой MIME сниффер, который пытается определить переданный тип файлов. На просторах инета можно встретить веб-серверы, которые посылают response со страничкой с атрибутом Content-Type: text/plain, хотя эта самая страничка на HTML. MIME сниффер определяет, что в теле ответа присутствуют HTML тэги, и решает, что нужно рендерить как HTML. Но как говориться, ни одно доброе дело не остается безнаказанным, и MIME сниффер играет нередко злую шутку. Например, можно создать специальный JPEG файл, содержащий скрипт, и когда пользователь зайдет на страницу с картинкой, браузер выполнит замаскированный скрипт. Теперь IE8 не будет снифать ответ с атрибутом image/* (до этого он снифал, «понимал», что перед ним HTML/Script и выполнял его :) ). Стало безопаснее, ничего не скажешь)

Введен новый атрибут, передаваемый через http заголовок:
— authoritative=true – запрещает MIME сниффинг
Пример: Content-Type: text/plain; authoritative=true; — страница отобразится как чистый текст, а не HTML.
И еще
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
Позволит сохранить файл на диске, но запретит выполнить его сразу же. Таким образом, если файл содержал опасный код, выполняться он будет уже не в контексте сайта, предотвращая тем самым атаку.

4. Add-on Security
Использование Data Execution Prevention Memory Protection больше не даунит ишака. Некоторые адд-оны из-за DEP роняли IE7, поэтому он был отключен. В IE8 все ОК, работает по умолчанию. Подробнее blogs.msdn.com/ie/archive/2008/04/08/ie8-security-part-I_3A00_-dep-nx-memory-protection.aspx

Per-Site ActiveX – защитный механизм для предотвращения использования контролов «со злым умыслом». Да и вообще ActiveX поправили (http://blogs.msdn.com/ie/archive/2008/05/07/ie8-security-part-ii-activex-improvements.aspx). Хотя использовать его только там, где без него, ну вообще никак.

5. Protected Mode
Eсть и в IE7. Сделано много улучшений в API. Должно по идее предотвращать незаметные установки опасного кода.
Только вот пугает фраза «For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone». Технология явно сыровата 

6. Application Protocol Prompt
Теперь появляется окошко с вопросом, хотите ли вы запустить что-то напрямую из браузера (например, потоковое медиа).

7. File Upload Control
Cтарый добрый аплоад. Теперь текстовое поле в диалоге с выбором файла доступен только для чтения. Также IE8 вместо C:\users\ericlaw\documents\secret\image.png image.png отправит лишь image.png, то есть инфа локального характера, не уйдет в инет.

8. Social Engineering Defenses
Очень громкое название. Непонятно, как может программа научить людей быть менее наивными и доверчивыми. В общем, антифишинг одним словом.
Address Bar Improvements – теперь в адресной строке имя домена черное, а все остальное серое. Сделано это, чтобы юзер отличал зерна от плевел. А то зрение рассеянно, и не сразу отличишь paypal.com от paypal.com.evil.org. К слову, все равно не видно разницы. На моей LCD черный и серый цвет под некоторым углом идентичны.
SmartScreen® Filter – как раз то самое развитие антифишинга. Теперь каждый раз, когда при попытке зайти на «плохой» сайт, будет появляться окошко: «Туда не хади, сюда хади». И вежливо предлагать хоумпейдж. Хотя можно и отказаться :)

Все то же самое, но в строгом стиле, без моих комментариев и на английском можно найти тут: blogs.msdn.com/ie/archive/2008/05/07/ie8-security-part-ii-activex-improvements.aspx

Вот такой он должен быть, новый IE. Надеюсь, что он действительно будет безопаснее. К слову, бета IE8 мне пока совсем не понравилась – но вдруг будет хэппи энд. Защита от XSS дейсвительно хорошая фича.

Ps: No holywars please