Csp расшифровка

CSP РАСШИФРОВКА ЭЦП

Время на прочтение

Content Security Policy (CSP) — это механизм безопасности веб-приложений, который используется для сокращения рисков, связанных с атаками, такими как внедрение скриптов (XSS) и выполнение нежелательного кода (инъекция). C SP позволяет веб-разработчикам указывать браузерам, из каких источников разрешено загружать ресурсы, такие как скрипты, стили, изображения, шрифты и другие элементы.

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

Это помогает предотвратить атаки, основанные на выполнении вредоносного кода из внешних источников, а также уменьшает риски, связанные с подделкой источников, перехватом данных и другими видами атак. C SP является эффективным инструментом для укрепления безопасности веб-приложений и защиты пользователей от различных видов уязвимостей.

Что дальше?

При локальной разработке у меня используется сервер на node.js «start»: «node scripts/start.js»

Но для нашего тестирования CSP нам потребуется настраивать заголовки на сервере, и самым популярным решением является поднять локально сервер на nginx вместо нашего скрипта.

Nginx Шаг 1

В зависимости от вашей os, команды по установке и запуску nginx могут немного отличаться. Так как я использую mac os, я устанавливал nginx через brew (https://brew.sh)

После того как мы установили nginx, у нас есть доступ к базовой конфигурации.

Для Mac Os nginx лежит по адресу /usr/local/etc/nginx либо /opt/homebrew/etc/nginx/nginx.conf базовый конфиг nginx.conf

Первое что я хотел сделать — чтобы nginx, для начала, просто отдавал мою статику.

Поэтому мой базовый конфиг для локальной работы выглядел так:

В данном случае наш сервер должен отдавать статику по адресу http://localhost:3000/

Теперь можем запустить nginx командой sudo nginx

Если мы перейдем по адресу http://localhost:3000/ то должны увидеть что то вроде этого:


CSP РАСШИФРОВКА

Nginx Шаг 2

Теперь нам нужно сбилдить нашу статику и положить ее в usr/local/var/www или /opt/homebrew/var/www

В моем проекте это делается командой yarn run build

На выходе получаем папку static, берем ее внутренности и перемещаем в usr/local/var/www

После этого перезапускаем nginx командой sudo nginx -s stop && sudo nginx

Теперь на http://localhost:3000мы должны увидеть наше приложение

P. S Этот шаг нужно повторять каждый раз, когда вы обновляете код своего приложения, если хотите проверить результат

Nginx Шаг 3

Далее будет не лишним настроить протокол https, чтобы наш сайт открывался по https://localhost:3000

Для этого нам нужно сгенерировать ssl сертификат. В терминале переходим в папку, в которую сгенерируем 2 новых файла. Лично мне удобно открыть WebStorm со своим проектом, и использовать встроенный терминал.

Вводим в терминал команду openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

После выполнения команды жмем enter чтобы скипать шаги до шага Common name.

На этом моменте для Common name вводим 127.0.0.1

чтобы установить сертификат в корневом хранилище сертификатов вашей ОС или в браузере, чтобы он был надежным.

В корне проекта появиться два файла cert.pem key.pem

Далее нам нужно перенести эти два файла в папку /usr/local/etc/ca-certificates или /opt/homebrew/etc/ca-certificates

И в конфиге nginx добавить следующие поля ниже поля server_name

P. S Опять же путь до файлов может отличаться

ssl_certificate /usr/local/etc/ca-certificates/cert.pem;

ssl_certificate_key /usr/local/etc/ca-certificates/key.pem;

Так же требуется добавить приписку ssl для поля listen

Получиться примерно так:

Теперь сайт должен открываться на https://localhost:3000

Nginx Шаг 4

По идее сейчас все готово для того чтобы внедрять политику CSP.

Для того чтобы ее настраивать нам нужно понимать как она работает.

А работает она с помощью заголовка Content-Security-Policy, мы будем описывать правила, которые браузер должен будет соблюдать, а если какое-либо действие пользователя будет не по правилам — браузер откажется это выполнять.

Настройка начинается с того, что сначала мы запрещаем все, а потом начинаем добавлять исключения.

Начнем с правила script-src оно определяет допустимые источники JavaScript.

В nginx  добавляем заголовок со следующим значением:

add_header Content-Security-Policy «script-src ‘self’ ‘unsafe-inline'»;

В коде это выглядит так:

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


CSP РАСШИФРОВКА

Это говорит нам о том, что у нас есть источник который не описан в политике csp, и поэтому браузер его не загружает, давайте добавим источник в список разрешенных.

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

Nginx Шаг 5

Казалось бы мы настроили первое правило script-src — но нет. В нашем правиле есть ключевое слово ‘unsafe-inline’ который означает что мы разрешаем использование всех встроенных скриптов. Использование этого ключевого слова считается небезопасным.

Давайте попробуем удалить это ключевое слово, и посмотреть что будет:


CSP РАСШИФРОВКА

Высокая вероятность того что вы получите такую ошибку выше, и скорее всего подобных ошибок будет +- около 10, а то и больше, в зависимости от того сколько встроенных скриптов вы используете.

Так что же тут случилось, откуда тут вообще взялась эта ошибка?

Так как мы отказались от ключевого слово ‘unsafe-inline’ — то мы отказались и от использования встроенных скриптов. Теперь же нам нужно научиться “помечать” какие встроенные скрипты являются безопасными.

Хорошей практикой считается добавлять для наших встроенных скриптов атрибут nonce, и указывать в нем динамический хеш, тем самым валидируя скрипты. Этот динамический хеш будет генерироваться нашим сервером nginx. Таким образом, если встроенный скрипт не будет иметь хеш, или он будет не совпадать — то nginx откажется его подгружать, тем самым мы себя обезопасим от разных атак.

Настройка хеша, включает в себя изменение кода как со стороны frontend так и со стороны nginx.

Для начала начнем со стороны frontend. В целом, описанные ниже шаги можно применить на большинство фреймворков и библиотек, так как основные настройки делаются в корневом index.js и в webpack конфиге.

Настройка frontend приложения

Сама настройка заключается в том, что мы должны добавить атрибут nonce=»CSP_NONCE» ко всем встроенным скриптам. Само значение CSP_NONCE на самом деле может быть любым. Это значение нужно для того, чтобы бы в будущем наш nginx находил это значение в статических файлах js, html и заменял на динамический хеш.

Начнем с простого, зайдем в наш index.html файл, и добавим этот атрибут ко всем подключаемым скриптам, стилям и шрифтам. К примеру у меня есть следующие скрипт и шрифт, в которые я добавляю атрибут:

Добавляем в наш index.html следующую запись

На эту запись могут ориентироваться некоторые UI библиотеки, например Material UI

Так же добавляем в index.html следующий скрипт

Тут мы глобально задаем новую переменную webpack_nonce на которую будут ориентироваться некоторые скрипты и библиотеки.

Как правило в этом месте описаны настройки для различных плагинов eslint, html.

ЭЦП:  РОССИЙСКИЙ АУКЦИОННЫЙ ДОМ ИСТОРИЯ СОЗДАНИЯ И ДЕЯТЕЛЬНОСТЬ ОТРАСЛЕВЫХ ВЫСТАВОК

Нам нужно установить плагин html-webpack-inject-attributes-plugin

Подключить его вверху конфига:

И добавить следующую запись последним элементов массива plugins

Так как использую react, у меня есть скрипт scripts/build.js, который запускается командой yarn run build , этот файл используется для сборки приложения в production

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

process.env. INLINE_RUNTIME_CHUNK = «false»;

Открываем наш корневой index.js, и в самый вверх добавляем запись:

// eslint-disable-next-line no-undef
__webpack_nonce__ = window.__webpack_nonce__;

По идее все эти шаги должны привести к тому, что каждый ваш встроенный скрипт, стиль, включая динамические, будет иметь атрибут nonce=»CSP_NONCE» :

Nginx Шаг 6

После того как мы добавили nonce=»CSP_NONCE» ко всем встроенным скриптам и стилям, нужно расширить конфигурацию nginx, и добавить:

Два поля в раздел location:

sub_filter **CSP_NONCE** $request_id;

Поле sub_filter_once указывает следует ли искать каждую строку для замены один раз.

Поле sub_filter задает строку для замены и строку замены.

То есть мы находим строку **CSP_NONCE** в нашей статике, и заменяем ее на значение переменной $request_id

Из заголовка удаляем строку unsafe-inline которая разрешала нам использование всех встроенных скриптов, и добавляем ‘nonce-$request_id’ и ‘strict-dynamic’

‘strict-dynamic’ — указывает, что доверие, явно предоставляемое скрипту, присутствующему в разметке, путем сопровождения его одноразовым значением или хэшем, должно распространяться на все скрипты, загруженные этим корневым скриптом.

Теперь наш каждый встроенный скрипт будет помечен динамических хешем, тем самым подтверждая что это наш скрипт и его можно загружать.

После перезапуска nginx, у нас должны пропасть ошибки из консоли.

Nginx Шаг 7

Теперь продолжим добавлять различные директивы, например style-src со значением self

Перезапускаем nginx, обновляем страницу, и смотрим ошибки в консоли.

Скорее всего самые первые ошибки будут указывать на ресурсы, которых нет в white list.

Добавляем ресурс и nonce:

style-src “’self’ ‘nonce-$request_id’ https://*.example.com”

Так же для удобства, выносим каждую директиву в переменную, и получаем:

По такому принципу, вы можете добавить остальные директивы.

У вас получиться примерно так:

В целом на этом моменте можно считать настройку CSP завершенной.


CSP РАСШИФРОВКА

Когда весь мир внезапно и не по доброй воле перешел на удаленку, даже завзятые скептики признали, что электронный документооборот — вещь полезная и нужная в корпоративном хозяйстве. Если судить по статистике продаж, то можно сделать вывод, что практически не осталось организаций, где хоть какая-то СЭД не внедрена.

Однако пандемия показала, что в реальности плавать получается не у всех бизнес-процессы по работе с документами автоматизированы далеко не у всех.

Дело в том, что в «мирное» время СЭД зачастую внедрялись формально, для галочки — при этом у людей оставалась возможность взять в руки бумажный документ и отмаршрутизировать его по нужным кабинетам. Пандемия такую практику пресекла на корню, и пришлось работать в СЭД по-настоящему, а не притворяться — тут-то все вскрылось. Как любит говорить Уоррен Баффет, «отлив покажет, кто купался без плавок».

Говорим «СЭД», подразумеваем «ECM» — и наоборот

Исторически повелось, что все средства автоматизации офисной бюрократии у нас называют «СЭД» — системы электронного документооборота, и этот рынок существует уже тридцать лет. За этот период сменилось несколько поколений систем, и для каждого на Западе придумывали новые термины — сначала были RM-системы (Records Management), потом EDMS (Electronic Document Management System) и, наконец, ECM (Enterprise Content Management).

Тем временем российские продукты продолжали именовать «СЭДами». Некоторые из них доросли до полноценных ECM, не уступающих импортным аналогам, другие же законсервировались на уровне начала нулевых. Поэтому чтобы понять, что за продукт перед вами, надо смотреть не на его этикетку, а на архитектуру и стек технологий. Но в обиходе аббревиатуры СЭД и ECM стали практически взаимозаменяемы.

ECM приказал долго жить? Отнюдь

Довольно долго на глобальном рынке электронного документооборота царила стабильность — концепция ECM была общепризнанной, в магическом квадранте Gartner из года в год присутствовали одни и те же лидеры и казалось, что тема себя исчерпала. В общем, картина была как в физике начала прошлого века накануне появления теории относительности и открытия элементарных частиц.

И вдруг внезапно в 2017 году Gartner заявляет, что «ECM умер». И говорит, что отныне это будет рынок CSP — Content Services Platforms. Что стоит за этим заявлением и что такое CSP, мы поговорим чуть ниже, а пока специально для спокойствия вашего финдиректора нужно сказать, что речь не идет о том, чтобы взять и выбросить все ECM и купить вместо них CSP. Это эволюционный процесс. Более того, по оценке Mordor Intelligence, глобальный рынок ECM к 2025 году достигнет более 93 миллиардов долларов, то есть за пять лет его стоимость удвоится.

Это значит, что инвестиции в ECM резко не обнулятся, а продолжат работать на благо вашей компании, однако вектор развития надо скорректировать с учетом появления новой концепции — CSP.

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


CSP РАСШИФРОВКА

Предпосылки появления CSP

Так откуда эти CSP взялись? Конечно, есть соблазн списать все на происки аналитиков, которые выдумывают новые сочетания из трех букв, чтобы продать побольше своих отчетов. Но это было бы слишком просто.

На самом деле накопился пул проблем, которые в рамках ECM не находят решения, и это вызывает фрустрацию у заказчиков. С другой стороны, в ИТ возникли новые глобальные тренды, и на их фоне подход ECM выглядит весьма олдскульным. В общем, назрела революционная ситуация — поставщики не могут удовлетворить клиентов, пользователи не хотят страдать от неудобных продуктов. Вот тут и выходит на сцену CSP, который по сути наследует функциональность ECM, однако реализует ее на основе современных архитектурных паттернов и с большим вниманием к пользовательскому опыту (UX).

То есть Content Services Platform — это следующий этап в области управления корпоративным контентом, который обеспечивает переход от автономных систем и репозиториев к открытым сервисам. В то время, как ECM сосредоточен на сохранении и защите контента, CSP используют инновационные технологические достижения, чтобы расширить фокус и обеспечить совместное использование контента и совместную работу пользователей.

Впрочем, давайте обо всем по порядку.

Почему ECM разонравился клиентам

Если в двух словах, то ECM — это долго и дорого. Потому что классические ECM создавались как монолитные продукты, которые за годы своего развития превратились в неповоротливых монстров, когда даже небольшая кастомизация выливается в проект минимум на полгода.

Раньше, когда вещи делались в расчете на очень долгое использование, это было нормально. Можно было потратить время и деньги на проектирование и разработку, а потом много лет эксплуатировать систему. На Кубе до сих пор ездят машины 50-х годов, им все трын-трава.

Сегодня концепция поменялась — вещи должны удовлетворять сиюминутные потребности клиентов и появляться на рынке быстро. Параметр Time-to-Market стал одним из главных при оценке проектов, внедрение изменений в системе должно происходить не за 2-3 года, как раньше, а за 2-3 месяца.

При этом срок службы изделий изрядно сократился — современный автомобиль в принципе столько не проживет, как выпущенный в середине двадцатого века. Сегодня люди хотят пользоваться вещами, а не владеть ими (поэтому Сбер недавно вообще предложил брать авто по подписке — совсем как SaaS).

Эти веяния коснулись и сферы документооборота — бизнес-процессы стали изменчивы, пользователи более искушенными и требовательными. И к тому же появилось огромное количество интеграционных задач, в которых трудно провести границу, где заканчивается документооборот и начинается что-то еще. Все это вместе взятое ставит ECM в очень трудное положение.

ЭЦП:  КАК ПОЛЬЗОВАТЬСЯ ЕГАИС ЛЕС

Основная претензия Gartner к решениям класса ECM — это наличие централизованной корпоративной платформы, которая не способна решать тот круг задач, на который она претендует. К таким ключевым платформенным задачам ECM относят комплаенс (соответствие нормативным требованиям) и управление рисками, функции базы знаний, обеспечение эффективности затрат и процессов, а также поддержку новых способов работы с контентом, в том числе с использованием ИИ.

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

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

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

Микросервисы — наше все

Справедливости ради стоит сказать, что так вели себя не только ECM, а все бизнес-приложения — ERP, CRM и другие. При этом построение интегрированных решений превращалось в кошмар для архитектора и приводило к дублированию данных во множестве репозиториев. Причина кроется не в злом умысле или некомпетентности разработчиков, а в резко возросшей сложности систем и динамичности связей между их элементами. Попыткой разрубить этот гордиев узел и стало обращение к микросервисной архитектуре, чтобы заменить монолитные ECM на нечто более гибкое.

Итак, по определению Gartner, Content Services Platforms — это набор служб и микросервисов в виде интегрированного набора продуктов или в виде отдельных приложений, которые используют общие API и репозитории. Они обслуживают отдельные виды контента для различных бизнес-задач организации.

CSP предоставляет все функции управления контентом, которые ранее были частью ECM: управление документами, управление записями, управление рабочими процессами, автоматизация бизнес-процессов, сбор и индексирование данных, классификация и категоризация данных, аналитика, архивирование и удаление данных.


CSP РАСШИФРОВКА

По материалам конференции Микросервисная архитектура в управлении корпоративным контентом», 23 апреля 2020. Подробнее

Однако благодаря новой архитектуре CSP существенно отличается от ECM.

Все для блага человека

Среди прочих претензий к ECM самой наболевшей, пожалуй, можно назвать претензию к качеству интерфейса и пользовательскому опыту. Едва ли какие-то корпоративные продукты получали в свой адрес столько негативных эмоций, как СЭД, потому что в документооборот вовлечены сотрудники всех подразделений, и все в равной степени страдают от необходимости делать кучу лишних движений, чтобы выполнить какое-то простое действие.

И это тоже следствие монолитной архитектуры — когда есть один продукт, реализующий много функций, он поневоле будет сложным. На это еще накладывалось пренебрежение разработчиков элементарными нормами юзабилити, поскольку СЭД часто внедрялись при помощи административного ресурса, «не хочешь работать в системе — увольняйся».

Здесь снова помогает декомпозиция монолита на отдельные сервисы — вместо того, чтобы пользователи обращались к специальной системе для работы с контентом, контент становится доступным непосредственно в текущем контексте задачи пользователя.

Джон Манчини, президент и главный евангелист AIIM, красочно сравнивает эту ситуацию с покупкой напитков отдельными порциями или целыми галлонами (это почти 4 литра). Ну действительно, иногда нам достаточно и пинты (1/8 галлона, если кто забыл). Аналогично, зачем человеку пробираться через множество экранов, когда ему всего-то нужно согласовать документ?

Open Source спешит на помощь

Еще одним аргументом в пользу отказа от монолитов стало разнообразие и доступность Open Source-компонент. Практически любая функциональность, которую только можно вообразить, скорее всего уже существует в виде СПО, надо только найти и встроить. Конечно, вопросы качества и безопасности открытого кода никто не снимал, однако они решаемы. Тогда как ставка исключительно на собственные ресурсы бесперспективна.

Пожалуй, ярче всего эта тенденция заметна в области BPM-движков. Если взять СЭД поколения нулевых годов, то в большинстве из них движки были самописные — потому что ничего достойного в свободном доступе не было, а лицензирование проприетарного продукта влетело бы в копеечку. И хотя фича управления процессами в системе важна, однако это все-таки не профильная специализация для разработчика ECM, потому и выглядели эти решения как сделанные на коленке.

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

Кроме BPM есть построители отчетов, мессенджеры, поисковые движки, средства просмотра документов, встроенные редакторы, планировщики, брокеры сообщений и огромное количество самых разнообразных библиотек. На базе СПО можно собрать практически любую корпоративную систему, не только CSP.

Электронный архив абонентских договоров для Tele2

Системами CSP уже активно интересуются телеком-компании. А именно они, как мы помним, самые прогрессивные в выборе ИТ-решений. Так, компания Tele2 создала электронный архив на CSP-платформе (платформа DocsHouse, разработка ЛАНИТ). Оператор выбирал из порядка десяти решений для управления корпоративным контентом от разных поставщиков и в итоге принял решение в пользу именно такой архитектуры: она, по его мнению, наиболее технологична.

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

Проект в Tele2 и другие проекты внедрения CSP в российских организациях будут представлены на онлайн-конференции ЛАНИТ,  которая пройдет 27 апреля https://docshouse.ru/conference2021.

Статья написана в соавторстве с d_levinsky и stas_makarov

Content Security Policy (CSP) — стандарт безопасности для веб-разработчиков. C SP описывает политики, ограничивающие список источников, из которых можно загружать скрипты и элементы оформления при открытии сайта в браузере. Также с помощью CSP можно запретить использование незащищенного канала для загрузки таких элементов. Политики CSP задаются в коде сайта и позволяют снизить риск атак с внедрением стороннего кода, таких как межсайтовый скриптинг (XSS).

Идею Content Security Policy разработал Роберт Хансен (Robert Hansen) в 2004 году. Документ назывался Content Restrictions и на тот момент нигде не применялся. Первым браузером с поддержкой Content Restrictions стал Firefox 4, выпущенный в 2011 году, а первая версия собственно стандарта CSP, Level 1, вышла в 2012-м под эгидой Консорциума Всемирной паутины (W3C). Актуальной версией на 2023 год является проект стандарта CSP Level 3, опубликованный в 2018 г.

CSP имеет статус рекомендации W3C. Стандарт поддерживают все основные браузеры. Firefox работает с актуальным синтаксисом CSP начиная с версии 23, Chrome — с версии 25, Safari — с версии 7. Браузеры, которые не поддерживают директивы CSP, игнорируют их и отображают в том числе запрещенный ими контент.

Как работают директивы CSP

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

ЭЦП:  КАК ПОЛУЧИТЬ ПОДПИСЬ В НАЛОГОВОЙ ДЛЯ ООО

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

Задачи CSP

Стандарт Content Security Policy направлен в первую очередь на борьбу с атаками, связанными со встраиванием стороннего кода на сайт. Инструкции могут защитить от такой вредоносной активности, как:

Также с помощью CSP разработчики могут получать отчеты о заблокированных элементах. Это позволяет отслеживать вредоносную активность на сайте.

Стоит отметить, что CSP не дает стопроцентной гарантии защиты. Злоумышленники могут использовать для своих нужд легитимные источники скриптов, например сервис Google Analytics, который многие разработчики указывают в числе доверенных источников. Поэтому рекомендуется использовать CSP не вместо, а в сочетании с другими методами защиты от подобных атак.

A website can declare multiple CSP headers, also mixing enforcement and report-only ones. Each header will be processed separately by the browser.

Mode of operation

Mapping between HTML5 and JavaScript features and Content Security Policy controls

If the Content-Security-Policy header is present in the server response, a compliant client enforces the declarative allowlist policy. One example goal of a policy is a stricter execution mode for JavaScript in order to prevent certain cross-site scripting attacks. In practice this means that a number of features are disabled by default:

Browser add-ons and extensions exemption

CSP (Content Security Policy) — стандарт защиты сайтов от атак с внедрением контента, например XSS — межсайтового скриптинга. C SP описывает безопасные источники загрузки и блокирует ресурсы, которые не входят в «белый список».

CSP разработал Роберт Хансен в 2004 году. Сначала протокол появился в Firefox 4, а потом и в других популярных браузерах. А в 2012 году он вошел в список рекомендаций World Wide Web Consortium (W3C, Консорциума Всемирной паутины) — группы организаций, которая занимается разработкой стандартов для Всемирной паутины.

Для чего нужен CSP

По политике безопасности в интернете, каждый сайт должен обращаться только к своим данным (same-origin policy). На практике ресурсы постоянно взаимодействуют с другими источниками: социальными сетями, сервисами метрики, сетями доставки контента и т.д. Это используют злоумышленники. Они внедряют вредоносный код в подгружаемую на сайт внешнюю информацию, которую он считает безопасной. Цель CSP — ограничить список ресурсов, откуда может загружаться контент, например изображения для страницы.

Как работает CSP

Стандарт CSP сообщает сайту, какие источники данных заслуживают доверия, а какие — нет. Он работает по принципу «Что не разрешено (не упомянуто), то запрещено». Для этого на страницу добавляется HTTP-заголовок Content-Security-Policy и директивы. Каждая директива представляет собой «белый список», в котором через пробел прописаны источники контента. Администратор может дать доступ целому домену, его отдельным поддоменам или конкретной странице, уточнить допустимые правила взаимодействия с ними.

Основные директивы

Для каждой директивы должны быть прописаны значения. При этом правил из одной директивы не влияют на указанные в другой. Например, если на сайте в img-src помечено self, а в default-src — self и адрес http://cdn.example.com, то картинки будут загружаться только с собственного домена сайта.

Кроме источников, в директивах также прописываются правила:

Разработчики и системные администраторы, которые еще не решили, стоит ли внедрять CSP на сайтах, могут применять директиву Content-Security-Policy-Report-Only. В этом случае система защиты будет отмечать нарушения безопасности и отправлять CSP-отчеты, но не станет блокировать использование ресурсов даже из потенциально опасных источников.

Ограничение источников контента только исходным сервером (без поддоменов). Content-Security-Policy: default-src ‘self’

Можно получать контент с только с доверенного домена и его поддоменов. Content-Security-Policy: default-src ‘self’ *.trusted.com

От каких атак защищает CSP

На страницу сайта внедряется вредоносный код, связанный с сервером злоумышленника. Браузер доверяет источнику контента и выполняет директивы.

Как защищает CSP: администраторы сервера, на котором расположен сайт, могут составить «белый список» доменов, заслуживающих доверия. Так можно сократить или полностью исключить обращение к источникам потенциально вредоносного скрипта. Радикальный вариант защиты — глобальный запрет на исполнение скриптов.

Перехват пакетов

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

Как защищает CSP: сервер может указать, какие протоколы разрешено использовать. Стратегия безопасности передачи данных отмечает файлы cookie атрибутами secure и автоматически перенаправляет со страниц HTTP на их аналоги HTTPS. Сайты также могут использовать HTTP-заголовок Strict-Transport-Security, чтобы браузеры подключались по зашифрованному каналу. От перехвата пакетов это не защитит, но поможет избежать расшифровки.

Типы потенциально опасного содержимого

Это последовательности действий (сценарии), написанные на JavaScript, PHP, Perl, Python или другом скриптовом языке программирования. Скрипты описывают автоматические действия, которые будет выполнять функциональный элемент сайта — например форма оплаты или обратной связи.

Изображения

Хотя картинка (фото, баннер и т.д.) представляет собой набор пикселей, файл с ней размещается и отображается на сайте с помощью скрипта. Именно в сценарий, по которому работает изображение, злоумышленник может вставить вредоносный код.

Стили

Это описания внешнего вида страницы и ее элементов (надписей, кнопок, подсветок и т.д.) на языке CSS. Внедрив вредоносный код в стили, злоумышленник может нарушить отображение сайта или использовать стили для доступа к другой секретной информации — например паролям пользователей.

Медиа

Это анимированные изображения, видеоролики, аудиофайлы. Опасность исходит не от содержимого, а от скриптов и стилей, которые их описывают и заставляют работать на сайте.

Шрифты

С их помощью отображаются статьи, заголовки и другие текстовые элементы на сайте. Шрифт — текстовый файл, поэтому может являться непосредственным источником опасности. Другой вариант — использование описывающего его стиля как носителя вредоносного кода.

Объекты

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

Фреймы

Тегами frame и iframe описываются встраивания одних веб-страниц в контекст других. Например, с их помощью отображаются интерактивные карты с адресом компании в разделе «Контакты» на сайтах. Источник опасности — вложенный в основную страницу веб-документ или объект.

Манифесты

Это веб-приложения, которые пользователь может установить на экран гаджета или десктоп ПК. Они объединяют в себе признаки традиционного сайта и нативного ПО. Источник опасности — как код самого манифеста, так и используемые им сторонние ресурсы.

Уязвимости CSP

Несмотря на настройки, CSP можно обойти. Количество «лазеек» зависит от его поддержки браузерами. Например, Internet Explorer использует стандарт частично. В меньшем количестве уязвимости есть в браузерах вроде Google Chrome, Opera, Safari.

JavaScript внутри фрейма

Когда текстовый документ или изображение открываются на любом сайте, они автоматически преобразуются в HTML-страницу с помощью iframe. Внутри него можно прописать вредоносный код. Так как такие автоматически созданные веб-документы не имеют настроенного CSP, браузер выполнит прописанный код без ограничений.

Отсутствие CSP в ошибках сервера

Разработчики часто защищают только рабочие страницы. Если злоумышленник пропишет в фрейме страницы с ошибкой 404 (или другой с кодом 4**) свой скрипт, то сможет похитить данные.

Подгрузка скриптов с файлообменников

Некоторые сайты используют облачные хранилища данных (Яндекс. Диск, Google Drive и т.д.) как источники контента. В этом случае злоумышленник может разместить на виртуальном диске вредоносный файл или скрипт, который будет исполняться системой.

Большинство уязвимостей CSP связано не с его недостатками, а с неправильным использованием разработчиками. Корректное внедрение стандарта на сайте позволяет защитить ресурс и данные пользователей.

Look up CSP in Wiktionary, the free dictionary.

Оцените статью
ЭЦП64
Добавить комментарий