Декларируя безопасность

Недавно многие начали спрашивать меня, что я думаю о черновике спецификаций Content Security Policy от Mozilla Foundation. Тогда, в январе я зачислил себя в ряды поклонников данной идеи. CSP является механизмом декларирования безопасности, когда сайт сообщает о своих намерениях, и позволяет пользовательскому агенту их обрабатывать.

У механизма декларирования безопасности есть множество преимуществ:

· Сокращение рисков несовместимости – поскольку сайты должны сообщать о своих намерениях, новые функции безопасности могут быть добавлены в агент не влияя на совместимость.

· Ясные намерения – чётко указывая желаемые ограничения, браузеру больше не нужно угадывать намерения сайта. Например, объясняя, почему некоторые JS-скрипты и, в частности, скрипты frame breaking, не могут быть размещены поверх какого-либо элемента для предотвращения ClickJacking-атак, Кимберли Джонс (Kymberlee Jones) отметил: «Если вы создаете код, не думая о том, как избежать возможных уязвимостей безопасности, значит вы не очень хороший разработчик». Так как декларативные функции безопасности разрабатываются отдельно для уменьшения угроз безопасности, браузеры могут реализовать эти ограничения безопасности так, как посчитают нужным, и могут исправлять ошибки, обнаруженные в ограничениях, без влияния на иную функциональность.

· Простота использования – позволяя сайту декларировать свои политики безопасности, браузеры могут принимать некоторые решения безопасности от имени пользователя.

· Возможность аудита – очень просто написать утилиту, которая будет сканировать содержимое сайтов на предмет политик и их соответствия требованиям компании-владельца сайта.

У Internet Explorer в этой области очень хорошая история: HTTPOnly, фреймы Security=RESTRICTED, X-Content-Type-Options, X-Download-Options, X-Frame-Options – все эти функции являются декларативными функциями безопасности, впервые реализованными в IE. Теперь они поддерживаеются другими браузерами на разном уровне.

Идеи, лежащие в основе проекта CSP, не новы и являются всего лишь одним из предлагаемых вариантов декларативной безопасности, начиная от BEEP до песочницы HTML 5. В некоторых областях CSP пересекается с другими механизмами по ограничению скриптов, хотя если данный механизм будет успешным, скорее всего, новые директивы будут создаваться, чтобы предоставлять унифицированные спецификации доступных политик.

Несмотря на всю свою ценность, механизмы декларативной безопасности также имеют и свои минусы:

· Плагины – для того, чтобы плагины не были заблокированы сразу, их работа должна регулироваться политиками безопасности. Так как плагины создаются разнообразными разработчиками, это требование может оказаться трудно реализуемым при реальном развёртывании.

· Некорректная конфигурация – CSP имеет такую же ценность, как политика, настроенная администраторами, и сегодня основная масса сайтов страдает от брешей в безопасности из-за неправильно настроенных политик безопасности. Ира Винклер (Ira Winkler) заявляет, что правительственное исследование показало, что 70% вторжений в компьютеры является результатом проблем с настройкой.

· Новая возможность для атаки – большинство механизмов, используемых для реализации CSP, будут опробованы хакерами, подвергнуты всеобъемлющему изучению и протестированы на предмет уязвимостей.

· Отлаживаемость – веб-разработчики часто сталкиваются с серьезными проблемами при разработке своих страниц, а введение новых политик безопасности потребует обновления для чёткой индикации того, что содержимое было блокировано из-за политик безопасности. Сайты могут нечаянно установить перекликающиеся политики ограничения, и не выловить данную ошибку при всестороннем тестировании, что может привести к проблемам в работе.

· Динамическое содержимое – в некоторых случаях с использованием динамического контента (создание почты, авторинг блога и т.д.) автору рабочей политики будет тяжело доказать безопасность содержимого, так как пользователь может сам добавить содержимое в указанную страницу из источников, неизвестных разработчику.

· Принятие – возможно самой большой проблемой для CSP и конкурирующих предложений является то, что они предлагают безопасность типа «выключено-по-умолчанию». Хотя это очень хорошо для совместимости, это не очень хорошо для защиты сайтов и пользователей, так как их преимущества станут доступны только после того, как веб-разработчики обновят свои сайты. Для успеха CSP должен балансировать между гибкостью/мощностью и простотой/пониманием.

Ни одна из технологий безопасности не является панацеей и для полноценной защиты, как я думаю, браузеры должны предлагать оба механизма: мощные API безопасности для предотвращения XSS-атак и автоматизированную защиту, которая сможет защищать сайты, вебмастера которых не могут или не хотят обновлять код своего сайта.

Для борьбы с XSS-атаками в IE8 мы реализовали несколько способов сокращения поверхности для атаки, несколько новых API, а также новый механизм декларативной безопасности (X-* заголовки), о котором говорили выше. Но мы понимали, что сайты не сразу перейдут на эти новые API и функции декларативной безопасности, поэтому мы встроили в браузер XSS-фильтр, включённый по умолчанию, но не задающий никаких вопросов и не требующий внесения каких-либо изменений в код. Это обеспечивает защиту от наиболее распространённых XSS-атак.

Я рад прогрессу в области CSP, который, по моему мнению, сможет помочь сайтам защитить себя от непрерывно увеличивающего числа угроз. Вы можете оставить свои отзывы относительно черновика спецификаций CSP на этой страничке.

Эрик Лоуренс