Современные веб-приложения проложили границы между моделями веб-разработки. В области безопасности это подняло интересный вопрос – кто отвечает за безопасность веб-приложения, построенного на сложной иерархии платформ? Приложение на вершине стека, промежуточный компонент платформы или сам браузер?

Мы уверены, что ответственность за безопасность веб-приложения разделена между клиентом веб-обозревателя, компонентами веб-платформы (такими как ASP.NET) и самими веб-приложениями. Любое распределение ответственности за безопасность может при обнаружении очередной уязвимости привести к поиску виновных. Вот почему мы рекомендуем использовать в приложениях декларативные функции безопасности, которые однозначно устанавливают ответственность в период проектирования.

Пример

Недавно опубликованные Калифорнийским университетом в Беркли исследования демонстрируют любопытные изъяны, касающиеся новых сложных веб-платформ. Одна из этих проблем была связана с использованием API postMessage, который поддерживается в IE8 для публикации междоменного сообщения с использованием подстановочного параметра targetOrigin. Параметр targetOrigin, настроенный в качестве замены, позволяет сообщению просочиться к любой цели без подтверждения. Эта опасность раскрытия информация является причиной того, что разработчики спецификаций требуют от вызывающей стороны явно задавать targetOrigin:

Наконец, в черновом варианте HTML5.0 также оговаривается, что параметр targetOrigin для метода postMessage становится обязательным, а не опциональным. Это не позволит разработчиком делать ошибки, требуя четкого подтверждения целевого назначения сообщения, благодаря точному определению первоначального <URL> или группового символа <*>.

Одной из причин, способствовавших участию Microsoft в рабочей группе по разработке спецификаций HTML5 Web Messaging, было желание убедиться, что результат ее работы сможет быть встроен «безопасно по умолчанию» в такие продукты, как Internet Explorer.

Мы обновили документацию по API postMessage, чтобы лучше показать влияние параметра targetOrigin на безопасность.

В этом примере браузер предоставляет примитив, который, при правильном использовании, обеспечивает безопасность платформы. Более точно – предшествующие API postMessage методы попросту не предоставляют надежного способа для безопасной передачи сообщений.

Как помогают гарантии декларативной безопасности

При правильном использовании возможностей декларативной безопасности в обозревателе допускается использование новых сценариев, в то же время разработчики веб-приложений могут избежать потенциально ненадежных приемов на программном уровне. Эти возможности, в конечном счете, помогают сократить неопределенность и сложность обеспечения безопасности веб-приложений. Вместо того чтобы для достижения объективной безопасности полагаться на свойственное браузеру поведение, можно воспользоваться решением, которое предлагает сам браузер.

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

Подводя итоги, следует сказать, что очень важно использовать все преимущества поддерживаемых обозревателем возможностей декларативной безопасности. Правильная настройка параметра targetOrigin при использовании postMessage является одним из примеров. Для уменьшения угроз максимально полагайтесь на соответствующие возможности платформы при разработке и создании модели риска веб-приложений. Просто используйте эти технологии, чтобы быть уверенными, что ваши цели в сфере безопасности окончательно достигнуты.

Дэвид Росс (David Ross),

Главный инженер безопасности программного обеспечения

Microsoft Security Response Center