Как обеспечить защиту данных на вашем сайте: 6 полезных советов

0
4293
Добавить в избранное

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




Интернет основан на политике «одного источника». Только код mysite.com имеет доступ к данным cookie, хранилищу, ajax-запросам mysite-а. Он полностью изолирован от других доменов.

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

К счастью, возможно наложить определенные ограничения, используя CSP (политику защиты контента), которая предотвращает непредвиденные угрозы безопасности. CSP определяет, что разрешено и запрещено браузеру. Например, можно запускать скрипты на mysite.com, но только из файлов, а не встроенных тегов <script>.

Тестируйте свой сайт

Чтобы проверить, реализуется ли CSP на вашем сайте, зайдите на observatory.mozilla.org, введите адрес и нажмите Scan Me. Веб-сайты, не имеющие контентной защиты, будут оценены на F.

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

Внедрение политики защиты контента

Политика безопасности контента должна быть внедрена на каждую страницу сайта разработчиком или хостером. Она определяется с использованием HTTP-заголовка Content-Security-Policy на серверном языке (PHP, Node.js, Ruby и т. д.) или в конфигурационном файле сервера.

 

Позже мы скажем несколько слов о значении «policy-definition».

Серверные конфиги практичны, поскольку они применяют один хедер ко всем страницам, расположенным ниже в файловой иерархии. Однако можно задать политику безопасности и в <head> HTML-файла используя тег meta:

 

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

Определение политики защиты контента

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

Затем вы вспоминаете, что вместе с этим подгружаете стороннюю библиотеку с CDN, которая может появляться на некоторых поддоменах вашего домена. Тогда маска субдомена добавляется в список:

Следом вы осознаете, что на страницах запускаются встроенные скрипты:

Итак, мы установили политику для скриптов. Но мы не сказали ни слова о стилях, медиа, шрифтах и т. п., поэтому все это просто не загрузится. Исправим это упущение с помощью default-src:

Отметим, что объявления типов контента разделены точкой с запятой (;).

Теперь мы можем использовать нашу политику в конфиге сервера:

…или в мета теге страницы:

Рекомендации по политике защиты контента

Практичнее всего начинать со строгой политики по умолчанию default-src ‘none’; и затем по мере необходимости добавлять дополнительные разрешения. Хорошей отправной точной для большинства сайтов будет:

Это разрешает скрипты, стили, изображения и ajax-запросы из того же источника.

Откройте свою страницу в браузере и запустите консоль разработчика. О заблокированных ресурсах будет выведено сообщение вида:

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

Сервисы Google

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

(Разрывы строк были добавлены для удобства восприятия, в реальном коде они не используются).

Тестируйте снова

Наконец, протестируйте ваши страницы на observatory.mozilla.org  еще раз. Скорее всего, оценка политики защиты заметно улучшится.

Другие статьи по теме

Защита от темных сил: Межсайтовая подделка запроса

Разбираем по косточкам компьютерные сети: HTTP, TCP, REST

Интересуетесь веб-разработкой?

Подпишитесь на нашу рассылку, чтобы получать больше интересных материалов:

И не беспокойтесь, мы тоже не любим спам. Отписаться можно в любое время.




Добавить комментарий