Модель безопасности Интернета основана на политике единого источника. Каждый источник изолирован от остальной сети, и коды должны иметь доступ только к данным своего источника. Благодаря этой модели браузеры доверяют каждому коду, отображаемому на странице, поскольку он является частью источника безопасности страницы.

Атаки Межсайтовый скриптинг (XSS) используют это поведение путем внедрения вредоносного кода на страницу. С момента первого официального упоминания XSS в рекомендациях CERT в 2000 году исследователи и практики изучили способы обнаружения, предотвращения и смягчения этой проблемы. Несмотря на эти усилия, это по-прежнему одна из самых распространенных проблем безопасности в Интернете, и по мере развития сети обнаруживаются новые варианты.

Сегодня Политика безопасности контента (CSP) является одной из самых многообещающих мер противодействия XSS. Это декларативный механизм политики, который позволяет разработчикам веб-приложений определять, какие клиентские ресурсы могут быть загружены и выполнены браузером. Блокируя встроенные скрипты и разрешая загрузку данных только из надежных источников, CSP стремится обеспечить безопасность приложения, даже если злоумышленник сможет найти уязвимость XSS. В дополнение к своей основной цели, смягчению атак XSS и оповещению о них, CSP также предлагает защиту от кликджекинга и уязвимостей смешанного контента. Может показаться привлекательным использование CSP в качестве единственного механизма защиты приложения, но это скорее механизм глубокоэшелонированной защиты, который отвечает за смягчение последствий атак, прорывающих первую линию защиты.

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

Политика безопасности контента на практике

Чтобы включить CSP, все, что вам нужно сделать, это установить в заголовке Content-Security-Policy допустимую политику (ее можно включить в метатеге, но это имеет ограниченные возможности). Однако реализация CSP может оказаться непростой задачей. Преимущество безопасности в подавляющем большинстве случаев сконцентрировано в двух директивах, предотвращающих выполнение скрипта: script-src и object-src, или default-src при их отсутствии. Высокий процент включенных политик недооценивает важность object-src, что приводит к уязвимости, легко используемой плагинами, такими как Adobe Flash, которые выполняют JavaScript в контексте своей страницы встраивания. Злоумышленник, который может внедрять и выполнять сценарии, может обойти все ограничения всех других директив. Как правило, директивы, не связанные с скриптом, могут служить защитой от некоторых пост-XSS-атак или атак, не требующих выполнения скрипта, таких как эксфильтрация данных путем перехвата URI формы или фишинга путем подмены пользовательского интерфейса страницы с помощью стили, контролируемые злоумышленниками, но они повышают безопасность только в том случае, если CSP уже является эффективной защитой от XSS.

Наиболее распространенный обход выполнения скрипта вызван базовым предположением CSP о том, что домены, внесенные в белый список политики, обслуживают только безопасный контент. К сожалению, это не так. Существует несколько надежных сетей CDN, которые обслуживают устаревшие библиотеки или содержат небезопасные конечные точки JSONP. Практический пример — поведение популярной библиотеки AngularJS. Возможность управления шаблонами, анализируемыми Angular, можно считать эквивалентной выполнению произвольного JavaScript. По умолчанию он заблокирован CSP без ключевого слова unsafel-eval, поскольку Angular использует функцию eval() для оценки выражений песочницы. Однако Angular имеет режим совместимости с CSP (ng-csp), который позволяет вызывать произвольный JavaScript, несмотря на включенный CSP. Он оценивает выражения песочницы, выполняя символические вызовы. В этой интересной задаче вы можете увидеть несколько способов эксплуатировать размещенные библиотеки Google, внесенные в белый список.

Чтобы решить эту проблему, в CSP2 добавлены пути из белого списка, что позволяет разработчикам указывать пути вместо доменов (например, trust-site.com/library/script.js). К сожалению, это ограничение было ослаблено. Если источник из белого списка содержит конечную точку, возвращающую ответ 30x, этот перенаправитель можно использовать для загрузки ресурсов из надежного источника, даже если он не соответствует разрешенному пути.

Content-Security-Policy: script-src trusted.com cdn.com/trusted-script.js <script src="//trusted.com?redirect=cdn.com/evil-script.js">

Это приводит нас к предпочтительному способу использования CSP: строгому CSP. Он использует криптографические одноразовые номера (число, используемое только один раз) для проверки скриптов. Используя одноразовый номер, каждый скрипт может быть отдельно добавлен в белый список. Это означает, что даже если злоумышленник может найти XSS-уязвимость, значение одноразового номера непредсказуемо, поэтому злоумышленник не может внедрить действительный скрипт. Однако это может повлиять на динамически добавляемые скрипты. Библиотеки JavaScript могут не знать о CSP и не знать правильный одноразовый номер, динамически вставляемые скрипты будут заблокированы CSP. К счастью, есть новое исходное выражение script-src, strict-dynamic. Это предварительная спецификация в CSP3, не каждый браузер поддерживает ее. При использовании одноразовых номеров скрипты строгого динамического белого списка загружаются или генерируются источниками из белого списка.

Старые браузеры, не поддерживающие стандарт CSP3, будут игнорировать ключевые слова nonce- и strict-dynamic. Возможным решением для этого является использование ключевого слова unsafe-inline в директиве script-src в качестве запасного варианта. Это не даст защиты от XSS-уязвимостей, но позволит приложению работать корректно для каждого пользователя.

Основы CSP объясняются в нашем новом туториале!

Первоначально опубликовано на blog.avatao.com.