Автоматические заголовки Content-Security-Policy в Drupal 8
Одним из наиболее распространенных типов уязвимостей, о которых сообщается в Drupal Security Advisories, является межсайтовый скриптинг (XSS), при котором небезопасный JavaScript вводится на сайт пользователем и не фильтруется должным образом. Drupal 7 предлагает некоторые функции, такие как check_plain() и filter_xss(), для очистки введенного пользователем текста, но иногда значения теряются. Drupal 8 усиливает защиту, по умолчанию автоматически фильтруя в шаблонах Twig вместо того, чтобы полагаться на то, что разработчики не забывают фильтровать все. Браузеры представили еще один уровень предотвращения XSS с Политикой безопасности контента, где ваш сайт может указать ограничения браузера на то, какой JavaScript должен быть разрешен для выполнения.
Изначально ядро Drupal 8 могло бы ввести очень ограничительную политику, чтобы отключить встроенные скрипты и разрешить только JavaScript из собственного домена сайта, но это вызовет проблемы, как только будет установлен модуль, загружающий сторонний скрипт. Чтобы большинство сайтов Drupal могли легко начать отправку заголовка CSP для защиты своих сайтов и их пользователей, я начал создавать модуль Content-Security-Policy.
За занавесом
Библиотечная система в D8 внесла большое изменение в способ добавления CSS и JavaScript к ответам: все ресурсы должны быть указаны в предопределенной библиотеке через файл YML, а не добавляться по отдельности через drupal_add_css() / drupal_add_js(), а встроенные скрипты и стили больше не поддерживаются напрямую ¹. Это означает, что если модуль или тема не обходят библиотечную систему, существует способ надежно определить все источники CSS и JavaScript, которые использует сайт.
Существует исчерпывающий набор опций для ограничения любых типов внешних ресурсов, которые может загружать страница, таких как JavaScript, CSS, изображения, аудио и видео, фреймы и т. Д. Поскольку определения библиотек в настоящее время включают только CSS и JavaScript, модуль определяет только директивы script-src и style-src, а другие не ограничиваются. Это помогает устранить наиболее распространенные источники уязвимостей XSS, но в идеале должна быть установлена соответствующая директива default-src, чтобы помочь покрыть другие риски.
По умолчанию модуль добавляет политику в режиме только отчет, поэтому он будет вызывать предупреждения в консоли браузера, но не блокирует загрузку CSS или выполнение любого JavaScript. Как только ваш сайт загрузится без каких-либо предупреждений, вы можете переключить настройки модуля, чтобы применить политику.
Что дальше
Существуют пробелы, когда простого анализа библиотек сайта недостаточно для полной политики. Я написал новый модуль Google Analytics для Drupal 8, чтобы решить, что Google по-прежнему рекомендует включать встроенный скрипт, который вставляет тег скрипта в страницу, хотя есть вариант получше. Затем для отправки данных Google Analytics может использовать два метода: либо путем загрузки изображения с параметрами в URL-адресе, либо с помощью запроса AJAX. Соответственно, если директивы image-src или connect-src являются ограничительными, сайт может заблокировать свою собственную коллекцию аналитики.
Для устранения ограничений информации, доступной в настоящее время через определения библиотек, модулю необходим способ установки значений по умолчанию и ручного переопределения и API для других модулей для указания дополнительных значений политики. Хотя API может ввести еще одну ловушку или событие, я думаю, что можно просто построить поверх существующей библиотечной системы; модули могут добавлять дополнительные элементы в определения своих библиотек непосредственно в файле YML или с помощью hook_library_info_alter(), где значения необходимо устанавливать динамически.
Проверить политику можно только с помощью консоли браузера, но ее нельзя реализовывать на действующем сайте без добавления директивы отчетности. Модуль должен обрабатывать сохранение отчетов в журнале сайта и иметь возможность настройки для использования внешних сервисов, таких как Report URI.
Известные вопросы
Самая важная проблема заключается в том, что CKEditor 4 требует встроенных скриптов для работы. Модуль Content-Security-Policy в настоящее время создает только одну политику для применения к каждой странице на сайте, и, поскольку CKEditor является базовой библиотекой, он требует, чтобы 'unsafe-inline' всегда был включен. Лучшим компромиссом может быть включение изменений политики по запросу, чтобы только страницы, содержащие CKEditor, допускали встроенные сценарии.
В ядре есть два элемента, которые по-прежнему вызывают проблемы для директивы style-src. Первое связано с тем, что ядро включает Modernzr в тему администратора, что приводит к нарушению из-за встроенных стилей. Некоторые проблемы и запросы на исправление проблемы относятся к 2015 году, и в них не было последних обновлений, поэтому вам, возможно, придется некоторое время игнорировать это предупреждение.
Вторая проблема связана с тем, что Drupal 8 поддерживает Internet Explorer 9, который имеет ограничение на количество файлов CSS, которые могут быть включены на страницу с помощью тегов ‹link›. Чтобы обойти ограничение, CSS-файлы добавляются встраиваемыми с помощью правил CSS import, когда их слишком много, что может произойти во время разработки, когда агрегирование отключено. Модуль Content-Security-Policy должен разрешить встроенный CSS для предотвращения взлома сайта, но добавляет предупреждение на страницу состояния, чтобы рекомендовать повторно включить агрегирование. Ядро Drupal больше не поддерживает IE 9 или 10 с версии 8.4, и этот обходной путь можно удалить в версии 8.6, но если вам действительно нужно поддерживать IE9 с неагрегированным CSS, модуль Content-Security-Policy интегрируется с Модуль совместимости IE9, чтобы сохранить текущее поведение.
¹ Существуют обходные пути и для модулей, и для тем, чтобы по-прежнему добавлять встроенные CSS и JS, но я думаю, что их следует сильно обескураживать. Для универсальных модулей, скорее всего, существует стратегия, которая устранит необходимость во встроенном JS.
Если вас также интересуют заголовки безопасности HTTP в Drupal, вы можете проверить запись моего сеанса из Drupalcon Vienna Использование заголовков для повышения безопасности. И обязательно 👏 и поделитесь этой статьей тоже.
Чтобы пообщаться со мной лично, найдите меня на Pacific Northwest Drupal Summit 2018 или Drupalcon Nashville, где я буду выступать, или вы можете подать заявку на присоединение к команде Myplanet.
