Обзор пользовательских тем и модулей Drupal
В пользовательских темах и модулях Drupal наиболее вероятно появление векторов атак. Там есть код, который не используется широко, в отличие от кода для модулей и тем contrib. Поэтому он не так хорошо протестирован с точки зрения безопасности. В этой статье я рассмотрю базовый контрольный список, используемый для аудита пользовательского кода Drupal. Этот список можно использовать в качестве основы для аудита настраиваемых модулей и тем.
Маршрутизация
Начнем с анализа параметров, полученных от пользователя. Давайте посмотрим, каков их тип и как они фильтруются. Drupal позволяет использовать параметры в маршрутизации. Это динамические значения, неправильная обработка которых может создать векторы атаки. Если запрос создается на основе параметра и не фильтруется, это может, например, вызвать вектор атаки SQL-инъекции.
Затем мы должны взглянуть на конфигурацию доступа к маршрутизации , а именно — на разрешения, которые должны быть у пользователя для получения доступа. При объявлении маршрутизации нам необходимо определить требования, которым должен соответствовать пользователь, чтобы получить доступ к маршрутизации. Мы должны проанализировать необходимые разрешения для каждой маршрутизации, указанной в нашем пользовательском коде Drupal, и решить, подходит ли их уровень. Если указать слишком низкий или неправильный уровень необходимых разрешений, пользователи получат доступ к страницам, к которым у них не должно быть доступа. Это могут быть как страницы со списком статей на вашей странице, так и страницы со списком всех пользователей вместе со всеми данными, присвоенными данной учетной записи. По этой причине так важен аудит разрешений.
Формы
Сначала мы проанализируем правильность типов элементов и проверим, был ли использован правильный тип для данного поля. При анализе типов полей, используемых в форме, мы можем встретить поле, название и описание которого предполагают, что оно должно быть заполнено данными определенного типа. Однако определение поля может позволить заполнить поле другими типами данных. Мы должны убедиться, что определение типа элементов соответствует их назначению.
Следующим шагом будет анализ используемых методов проверки значений полей в форме. Drupal позволяет определять собственные методы, проверяющие правильность введенных данных. Мы должны проверить правильность пользовательских методов проверки и убедиться, что только действительные данные проходят проверку.
Последнее, что нужно сделать, это проверить наличие и правильность использования Form API, предоставляемого Drupal. Мы должны проанализировать способ использования Form API, желательно с помощью документации, и убедиться, что формы создаются в соответствии с указаниями.
В документации указано:
- случаи, когда использование данного типа поля является правильным;
- как создавать методы валидации;
- как использовать hook_form_alter;
- как создавать формы, которые будут интуитивно понятны для пользователя.
SQL запросы
Начнем с проверки наличия и правильного использования API базы данных, предоставляемого Drupal. Он оснащен методами, обеспечивающими защиту от атак на базу данных. Правильное использование API в значительной степени защищает от атак. Особо следует обратить внимание на то, используются ли методы фильтрации входных данных в SQL-запросах. Drupal рекомендует использовать заполнители, если есть необходимость использовать входные данные, например, из переменной, значение которой было указано пользователем в форме.
Вот пример:
$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = ‘ . $foo[‘name’]);
В приведенном выше коде мы видим, что значение name из массива $ foo присваивается запросу без фильтрации. В таких случаях я рекомендую использовать заполнители.
$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = :name’, [‘:name’ => $foo[‘name’]]);
Создавая запросы таким образом, мы подвергаем переменную $ foo ['name'] фильтрации, которая защитит запрос от атак SQL Injection.
Механизмы фильтрации
Это означает проверку наличия и правильности данных фильтрации, полученных от пользователя. Нам нужно убедиться, что для рендеринга переменных в шаблонах используется только TWIG, который по умолчанию фильтрует содержимое переменных и обеспечивает их безопасность. В случае работы с переменными, которые затем используются в переводимых строках, нам нужно убедиться, что эти переменные заменены соответствующими заполнителями. Простой текст, поступающий от пользователя, должен быть отфильтрован с помощью метода Html :: escape (), если пользователь не может предоставлять HTML-теги в тексте, и функции Xss :: filterAdmin (), если они должны иметь возможность делать так. Если пользователь предоставляет ссылки, их также следует отфильтровать.
Для этого используются функции UrlHelper :: stripDangerousProtocols () и UrlHelper :: filterBadProtocol (). Механизмы фильтрации также применимы на стороне клиента. Чтобы очистить текст в JavaScript, мы должны использовать функцию Drupal.checkPlain ().
Конфиденциальные данные
Мы должны проверить, не содержит ли код учетных данных или ключей API. В некоторых случаях мы можем встретить учетные данные, оставленные в коде настраиваемых модулей. Их выявление не требует особого труда.
Обзор сайта Drupal
Стоит заглянуть в код для поиска конфиденциальной информации, которая может храниться в файлах. Первый шаг — проанализировать файл settings.php и убедиться, что в нем нет учетных данных, которые предоставили бы доступ к базе данных или другим компонентам веб-сайта Drupal. Затем давайте пройдемся по файлам переменных среды и убедимся, что в них нет учетных данных. Учетные данные, необходимые для среды, не должны быть частью репозитория.
Следующий шаг — проверить, нет ли глубоко скрытых конфиденциальных файлов, например, с закрытыми ключами SSL или копиями или дампами баз данных. Иногда файлы, которые никогда не должны находиться в проекте, попадают туда по ошибке. Некоторые из них, например, дампы базы данных или закрытые ключи. Рекомендуется выявить и удалить их.
Выводы
Мы изучили способы проверки кода пользовательских модулей и тем, мы провели аудит сайта, чтобы убедиться, что никакие конфиденциальные данные не были общедоступными, и мы проанализировали элементы, на которые стоит обратить внимание в процессе аудита.
Применение советов, которые я опубликовал в этой статье, сделает ваше приложение более безопасным. Аудит кода — ключевой элемент, ведущий к повышению безопасности страницы. Это требует больше времени и знаний, чем обновление и правильная конфигурация Drupal, но преимущества от этого намного более ценны, чем время, потраченное на это.
Вам нужна помощь в выполнении такой задачи? Наша команда поддержки Drupal имеет большой опыт проведения аудитов.