Привет, меня зовут Кимберли Прайс (Kymberlee Price) и я недавно присоединилась к команде Internet Explorer в должности руководитель группы разработчиков по безопасности в IE8, и работаю совместно с Эриком Лоуренсом (Eric Lawrence). До этого я пять лет провела в команде Microsoft Security Engineering & Communications (MSEC), где в 2003 году я основала команду Security Researcher Community Outreach, а также провела три первые конференции BlueHat. Я присоединилась к команде IE в отличное время для того, чтобы следить за созданием новой функции, и думаю, что пользователям и исследователям безопасности может быть интересно узнать подробности о том, как это происходит.
В сентябре я переехала в новый кабинет, светило солнышко (даже в Сиэтле) и Роберт Хансен (Robert Hansen) и Иеремийя Гроссман (Jeremiah Grossman) готовились представить доклад на конференции OWASP, проходившей в Нью-Йорке, о новом виде угрозы безопасности, который они назвали ClickJacking. Так как через несколько недель начали появляться детали, потребовалось проводить их обсуждение. Я стала участником массы мозговых штурмов с такими экспертами по веб-безопасности, как Билли Риос (Billy Rios), Брайан Салливан (Bryan Sullivan), Дэвид Росс (David Ross), Эрик Лоуренс (Eric Lawrence), Спенсер Лоу (Spencer Low), а также членами Microsoft Research, например, Хелен Вонг (Helen Wang). В результате данных встреч стало ясно одно:
Прерывающий фрейм JavaScript часто представляют как механизм против ClickJack, но это не лучшее решение, так как есть способы обмануть прерывающие фреймы JavaScript. Кроме того, прерывающие фреймы JavaScript никогда не задумывались как способ смягчения ClickJacking. Если вы разрабатываете какую-то технологию не в качестве способа предотвращения использования уязвимости, то есть вероятность, что из этого ничего хорошего не выйдет.
Опции настройки браузера ограничены. За исключением использования зон безопасности или дополнений для отключения фреймов и скриптов (что серьезно ослабит функциональность браузера), пользователи браузера будут уязвимы для данного типа атак.
Поэтому мы очутились в ситуации, когда в IE не было способа смягчения данной уязвимости для конечных пользователей, чтобы они могли защитить сами себя и мы знали способы, как предотвратить ClickJacking-атаки. "Непобедимый" механизм потребовал бы внесения слишком серьезных изменений в код веб-приложения и было бы тяжело заставить относиться к таким рекомендациям серьезно.
Было самое время задуматься о разработке нового решения. Дэвид Росс разработал прототип инструмента, который на 5 секунд откладывал возможность щелкнуть по ссылке, при этом выводя адрес фактического сайта или домена, по которому щелкал пользователь. Несмотря на то, что это обеспечило бы пользователя защитой, такое решение серьезно бы повлияло на удобство работы с браузером. ClickJacking является довольно редкой атакой, которая является подмножеством гораздо большей проблемы Cross-Site Request Forgery. Если сайт не защищает сам себя от CSRF-угроз, то атакующему нет нужды возится с ClickJacking. Учитывая природу угрозы, создание механизма защиты, который усложнил бы пользовательский опыт работы, является неприемлемым вариантом.
В итоге мы решили, что лучшим вариантом функции защиты от ClickJacking, который мы могли добавить в IE8 во время цикла разработки браузера, это разрешить владельцу контента самостоятельно решать, должен ли его контент находиться во фрейме или нет. Это решение также было предложено Майклом Залевски (Michael Zalewski) на форуме WHATWG.
На разнообразных конференциях Эрик и я начали обсуждение с исследователями по безопасности потенциальной защиты от ClickJacking и в итоге получили данной обратной связи, что принятие решения о неразмещении контента в фрейме было достаточно разумным по сравнению с другими способами, которые привели бы к серьезным проблемам совместимости и простоты использования. Но мы все еще хотели получить дополнительные данные обратной связи от экспертов по сетевой безопасности, поэтому в начале декабря мы связались с несколькими производителями браузеров, создавая открытый форум по решению данной проблемы и предложению решений. Мы поделились своими планами, попросили об отзывах и стимулировали других разработчиков принять такую же модель в ближайшем будущем - мы хотим, чтобы были защищены все пользователи, независимо от используемого браузера.
Теперь, когда вышел RC1, а, следовательно, функция защиты от ClickJacking-атак стала публично доступной, наша работа закончена. Чтобы принять необходимые меры безопасности веб-разработчикам необходимо внести изменения в код для активации этой защиты у пользователей. Это означает тренировку наших "полевых" консультантов и персональных менеджеров. Я буду присутствовать на TechReady 8, проходящей на этой неделе, и первым ключевым моментом моего призыва к действию будет помощь крупнейшим компаниям-разработчикам в использовании преимуществ данной функции. Следующим пунктом будет создание плана миграции, чтобы обезопасить устаревшие браузеры - архитектурные изменения и инвестиции в безопасность, которые мы внесли в современные браузеры, весьма серьезны.