Пуленепробиваемый Ваш сайт Drupal

"><script>alert('blog-node-title');</script>

"><img src="u.png" onerror="alert('blog-node-title');"</script>

Drupal также позволяет изменениям конфигурации бороться с XSS. Для этого вы не должны использовать тип ввода PHP. Drupal имеет три формата по умолчанию (полный HTML, отфильтрованный HTML и PHP), которые пользователи используют при заполнении веб-форм. Отфильтрованный HTML на сегодняшний день является самым безопасным и должен использоваться по мере возможности для удаления вредоносных HTML-кодов (например, JavaScript).

Это обеспечит безопасность от XSS ( межсайтовый скриптинг ), а также от CSRF ( межсайтовый подделка запросов ). Хотя тип ввода PHP позволяет пользователям писать PHP непосредственно в существующий контент и позволяет серверу оценивать, он также привлекает злоумышленников. В случае необходимости включите разрешения, пока они не будут созданы. Короче говоря, он должен оставаться отключенным, когда он не используется.

Подделка межсайтовых запросов

Drupal Form API обеспечивает защиту от CSRF. Он использует специальные токены (в формах), которые постоянно обновляются. С модулем, использующим API-интерфейс Form для всех запросов на изменение данных и надлежащим образом выполненную документацию API-интерфейса , у CSRF мало шансов создать проблему. Для хорошего кода, см. Документацию Forms API . Обратные вызовы меню, уязвимые для CSRF, легко решаются путем добавления к каждой функции confirm_form() (форма подтверждения). Друпал делает все остальное.

Помимо отключения типа ввода PHP, вы можете использовать этот трюк и напрямую использовать генерацию токенов в Drupal. Это включает в себя добавление токена; добавленный токен будет возвращен с запросом на следующее действие и проверен перед выполнением действия. Маркер добавляется в ссылки функции security_review_reviewed а затем проверяется в security_review_toggle_check .

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

 $token = drupal_get_token($check['reviewcheck']); $link_options = array( 'query' => array('token' => $token), 'attributes' => array('class' => 'sec-rev-dyn'), ); 

 if (!drupal_valid_token($_GET['token'], $check_name)) { return drupal_access_denied(); } 

Однако, чтобы иметь дело с CSRF в модулях, добавленных в Drupal (например, ссылка типа <img src="http:// website-name/yourmodule/shoes/123/delete" alt="naked girls pic" /> ), форма подтверждения вместе с жетонами формы имеют первостепенное значение. Они спрашивают Вы уверены, что хотите удалить этот элемент? для ядра и модулей Drupal.

Итак, суть в том, что разумно использовать защиту токенов при создании ссылок и форм вручную.

SQL-инъекция и API базы данных

Менее достоверные данные в запросе к базе данных (например, каналы, пользовательские данные, некоторые другие базы данных и т. Д.) Не должны использоваться напрямую. У вас есть шанс испечь, если вы используете что-то вроде этого:

index.php?id=12mysql_query("UPDATE mytable SET value = '". $value ."' WHERE id = ". $_GET['id']);

Или, скажем, когда вы объединяете две строки данных в одну (конкатенацию), которая входит непосредственно в запросы SQL. Например,

 <?php db_query('SELECT FROM {table} t WHERE t.name = '. $_GET['user']); ?> 

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

db_query("UPDATE {mytable} SET value = :valueWHERE id = :id", array( ':value' => $value, ':id' => $id);

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

 <?php db_query("SELECT foo FROM {table} t WHERE t.name = '%s' ", $_GET['user']); ?> 

Для размещения аргументов в переменных числах в SQL помогает создание массива заполнителей. Итак, вместо:

 <?php db_query("SELECT ts FROM {table} t WHERE t.field IN (%s)", $from_user); ?> 

Лучше поставить:

 <?php $placeholders = implode(',', array_fill(0, count($from_user), "%d")); db_query("SELECT ts FROM {table} t WHERE t.field IN ($placeholders)", $from_user); ?> 

Использование db_rewrite_sql() функций db_rewrite_sql() с операторами SQL, ссылающимися на узлы (или {node}table ), остановит нарушение ограничений доступа к узлам. Это абсолютное требование к механизму, который обеспечивает доступ Drupal к его узлам; любое нарушение и это посторонние получают доступ к запрещенным узлам. Это сделано так:

 <?php $result = db_query(db_rewrite_sql("SELECT n.nid, n.title FROM {node} n")); ?> 

Резюме

Это был своего рода ускоренный курс по множеству видов уязвимостей, которые сводят пользователей Drupal с ума, но любой, кто был в этих бурных водах, будет знать, что мы рассмотрели три наиболее важных вопроса, а именно — внедрение XSS, CSRF и SQL, из которых первые два можно легко решить, если правильно следовать рекомендациям по настройке Drupal.

Сообщите мне в комментариях о вашем опыте с безопасностью Drupal и о том, хотите ли вы узнать больше по этой теме от меня.