Content Security Policy (CSP, политика защиты контента) — это механизм обеспечения безопасности, с помощью которого можно защищаться от атак с внедрением контента, например, межсайтового скриптинга (XSS, cross site scripting). CSP описывает безопасные источники загрузки ресурсов, устанавливает правила использования встроенных стилей, скриптов, а также динамической оценки JavaScript — например, с помощью eval. Загрузка с ресурсов, не входящих в «белый список», блокируется.
Принцип действия
CSP сейчас является кандидатом в рекомендации консорциума W3C. Для использования политики страница должна содержать HTTP-заголовок
Content-Security-Policy с одной и более директивами, которые представляют собой «белые списки». В версии 1.0 поддерживаются следующие директивы:
default-srcscript-srcobject-srcstyle-srcimg-srcmedia-srcframe-srcfont-srcconnect-src
В
default-src перечисляются разрешённые источники по умолчанию для остальных директив. Если какая-то директива не указана в заголовке, то политика применяется согласно списку default-src.
Для всех директив действуют следующие правила:
- Для ссылки на текущий домен используется
self. - В перечне URL адреса разделяются пробелами.
- Если в рамках данной директивы ничего не должно загружаться, то применяется
none. Например,object-src 'none'запрещает загрузку любых плагинов, включая Java и Flash.
Простейший пример политики, разрешающей загрузку ресурсов только указанного домена:
Content-Security-Policy: default-src 'self';
Попытка загрузки ресурсов из иных доменов будут пресекаться браузером с выдачей уведомления в консоли:
По умолчанию CSP ограничивает исполнение JavaScript путём запрета встроенных скриптов и динамической оценки кода. В комбинации с «белыми списками» это позволяет предотвращать атаки с внедрением контента. Например, XSS-атаку с внедрением тэга инлайн-скрипта:
Загрузка внешних скриптов, которые не включены в CSP, также будет пресечена:
На данный момент в перечне URL нельзя прописывать пути (http://ift.tt/1OfPorg), можно лишь перечислять сами домены (http://cdn.example.com). Зато поддерживаются символы подстановки, так что вы можете описать сразу все поддомены (http://*.example.com).
Директивы не наследуют права от предыдущих директив. Каждая директива, включённая в заголовок CSP, должна содержать перечень разрешённых доменов/поддоменов. В следующем примере default-src и style-src содержат ключевое слово self, а script-src и style-src содержат домен http://cdn.example.com:
Content-Security-Policy: default-src 'self';
style-src 'self' http://cdn.example.com;
script-src http://cdn.example.com;
Если вам нужно указать хосты для загрузки данных, то нужно указать ключевое слово
data: img-src 'data:';.
Помимо списков доменов, директивы script-src и style-src поддерживают ключевые слова unsafe-inline и unsafe-eval.
unsafe-inlineиспользуется для разрешения инлайн-стилей и скриптов<style>и<script>. Также это ключевое слово разрешает инлайн-атрибуты CSSstyle, инлайн-обработчики событий (onclick, onmouseover и т.д.) и javascript-ссылки наподобие<a href="javascript:foobar()">. CSP работает по принципу «если что-то не упомянуто, значит запрещено». То есть при отсутствии ключевого словаunsafe-inlineвсе инлайн-тэги<style>и<script>будут блокироваться.unsafe-evalиспользуется только в директивеscript-src. Если это ключевое слово не указано, то блокируется любая динамическая оценка кода, включая использованиеeval, конструктор функций и передачу строковых вsetTimeoutиsetInterval.
Поддержка браузерами
На текущий момент большинство браузеров и их версий уже поддерживают CSP 1.0. IE снова отличился: в 10 и 11 версиях обеспечена лишь частичная поддержка с помощью заголовка
X-Content-Security-Policy. Судя по всему, поддерживается только опциональная директива sandbox.
Получение отчётов о нарушениях CSP
Как уже упоминалось, сообщения обо всех нарушениях политики безопасности логгируются в консоли браузера. Это удобно, пока вы только разрабатываете сайт, но после развёртывания нужен более практичный способ получения отчётов о нарушениях. Для этого можно использовать директиву
report-uri. Каждый раз, когда регистрируется нарушение CSP, директива отправляет на указанный адрес запрос HTTP POST. В теле запроса содержится JSON-объект, в котором указаны все необходимые подробности.
Допустим, у нас есть такая CSP:
Content-Security-Policy: default-src 'self';
report-uri: http://ift.tt/1MQHSOS;
Это означает, что браузер может загружать ресурсы только с нашего собственного домена. Но нам нужно использовать сервис Google Analytics, который будет пытаться скачивать JavaScript с http://ift.tt/rzP4g5. А это уже нарушение нашей CSP. В этом случае
report-uri отправит запрос со следующим JSON:
{
"csp-report": {
"blocked-uri:" "http://ift.tt/nkWzpa"
"document-uri:" "http://ift.tt/LWARzD"
"original-policy": "default-src 'self'; report-uri http://ift.tt/1MBXF6r"
"referrer:" ""
"violated-directive": "default-src 'self'"
}
}
Content-Security-Policy-Report-Only
Если вы пока не уверены, стоит ли внедрять у себя CSP, то можно попробовать вместо заголовка
Content-Security-Policy использовать Content-Security-Policy-Report-Only. В этом случае CSP будет регистрировать нарушения без какого-либо блокирования ресурсов. Можно даже использовать одновременно Content-Security-Policy и Content-Security-Policy-Report-Only, обкатывая на второй те или иные конфигурации.
Прописывание заголовка
HTTP-заголовок можно прописать прямо в конфигурационных файлах на сервере:
# Apache config
Header set Content-Security-Policy "default-src 'self';"
# IIS Web.config
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self';" />
</customHeaders>
</httpProtocol>
</system.webServer>
# nginx conf file
add_header Content-Security-Policy "default-src 'self';";
Также многие языки программирования и фреймворки позволяют добавлять заголовки программно (например, PHP, Node.js):
# PHP example
header("Content-Security-Policy: default-src 'self'");
# Node.js example
request.setHeader("Content-Security-Policy", "default-src 'self'");
CSP в дикой природе
Давайте посмотрим, как CSP внедрён в Facebook:
default-src *;
script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com;
style-src * 'unsafe-inline';
connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net http://wss*.facebook.com:* http://ws*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://ift.tt/1ize5ik http://ift.tt/1kfU6Da;
Обратите внимание на использование символов подстановки для описания поддоменов, а также номеров портов в
connect-src.
А теперь вариант Twitter:
default-src https:;
connect-src https:;
font-src https: data:;
frame-src https: twitter:;
frame-ancestors https:;
img-src https: data:;
media-src https:;
object-src https:;
script-src 'unsafe-inline' 'unsafe-eval' https:;
style-src 'unsafe-inline' https:;
report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVZXO2LGOQ%3D%3D%3D%3D%3D%3D&ro=false;
Здесь везде прописаны
https:, то есть принудительно используется SSL.
CSP Level 2
Также является кандидатом в рекомендации. В CSP Level 2 сделаны следующий нововведения:
base-uri: позволяет документу манипулировать базовым URI страницы.- Вместо
frame-srcтеперь применяетсяchild-src. form-action: позволяет документу размещать HTML-формы.frame-ancestors: регламентирует способ встраивания данного документа в другие документы. Работает как заголовок X-Frame-Options, для замены которого, вероятно, и предназначен.plugin-types: разрешает загрузку конкретных плагинов — Flash, Java, Silverlight и т.д.
В JSON, содержащихся в отчётах о нарушениях, появились два новых поля:
effective-directive: здесь указано название директивы, которая была нарушена.status-code: HTTP-код состояния запрошенного ресурса. Если нарушающий запрос делался не через HTTP, то ставится 0.
Также в CSP Level 2 появилась возможность разрешать инлайн-скрипты и стили с помощью nonce-значений и хэшей.
Nonce — это генерируемая случайным образом на сервере строковая переменная. Она добавляется в CSP-заголовок:
Content-Security-Policy: default-src 'self';
script-src 'self' 'nonce-Xiojd98a8jd3s9kFiDi29Uijwdu';
и в тэг инлайн-скрипта:
<script>
console.log("Script won't run as it doesn't contain a nonce attribute");
</script>
<script nonce="Eskdikejidojdk978Ad8jf">
console.log("Script won't run as it has an invalid nonce");
</script>
<script nonce="Xiojd98a8jd3s9kFiDi29Uijwdu">
console.log('Script runs as the nonce matches the nonce in the HTTP header');
</script>
Если вы захотите использовать хэши, то сначала их нужно сгенерировать на сервере и включить в заголовок CSP, соответственно в директивы
style-src или script-src. Перед рендерингом страницы браузер вычисляет хэш скрипта/стиля, и если он совпадает с указанным, то выполнение разрешается.
Пример хэша, сгенерированного из строковой console.log('Hello, SitePoint'); с помощью алгоритма Sha256 (base64).
Content-Security-Policy:
default-src 'self';
script-src 'self' 'sha256-V8ghUBat8RY1nqMBeNQlXGceJ4GMuwYA55n3cYBxxvs=';
Во время рендеринга страницы браузер для каждого инлайн-скрипта вычисляет хэши и сравнивает с перечисленными в CSP. Приведённый выше хэш позволяет выполнить скрипт:
<script>console.log('Hello, SitePoint');</script>
Обратите внимание, что пробелы имеют значение, так что эти скрипты выполнены не будут:
<script> console.log('Hello, SitePoint');</script>
<script>console.log('Hello, SitePoint'); </script>
В заключение
Если у вас есть опыт использования CSP, — положительный или отрицательный, — поделитесь, пожалуйста, в комментариях. Также было бы интересно узнать о нестандартных задачах, которые вы решали с помощью CSP.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий