Безопасность PHP. Проверка поступивших данных

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

Виталий Желтяков
vita-zhelt@yandex.ru

Виды уязвимостей PHP

• Демонстрация ошибок пользователю
  Смысл: при каких-либо ошибках в коде пользователю выводиться информация об произошедшей ошибке. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера.
• Доступность данных о характеристиках системы пользователю
  Смысл: пользователь может получить доступ к данным, дающим представление о системе. Не является критичной уязвимостью, но поваляет взломщику получить дополнительную информацию о структуре и работе сервера. Причина этой уязвимости в ошибках и «недосмотрах» программиста. Примером может служить наличие файла phpinfo.php с одноименной функцией в свободном доступе.
• Доступность данных о программном коде пользователю
  Смысл: пользователь может получить доступ к программным кодам модулей, имеющих расширение, отличное от php. Является критичной уязвимостью, так как позволяет взломщику получить достаточно полную информацию о структуре и работе сервера, выявить его уязвимости.
• Простые пароли для доступа к административным страницам
  Смысл: взломщик может подобрать простой пароль к административной странице, дающей ему больше возможностей для взлома. Является критичной уязвимостью, так как позволяет взломщику повлиять на работу сервера.
• Возможность задания глобальных переменных
  Смысл: при неправильных настройках PHP имеется возможность задавать глобальные переменные скрипта, через строку запроса. Является критичной уязвимостью, так как взломщик может влиять на ход работы скрипта в свою пользу.
• PHP-инъекция
  Смысл: в параметр, определяющий работу PHP с файлами или программным кодом, передается ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере. Выполнение кода осуществляется при помощи функций:
  

  
  
  eval(),
  
  preg_replace(),
  
  require_once(),
  
  include_once(),
  
  include(),
  
  require(),
  
  create_function(),
  
  readfile(),
  
  dir(),
  
  fopen().

• PHP-инъекция через загрузку файлов
  Смысл: при возможности задании глобальных переменных в параметр, определяющий загружаемый на сервер файл, передаётся ссылка на сторонний программный код или конфиденциальный файл на сервере. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к конфиденциальным данным. Данная уязвимость возможна только при возможности задания глобальных переменных и неверной организации механизма загрузки файлов.
• E-mail-инъекция
  Смысл: в параметр, определяющий работу PHP с электронными письмами, передаётся ссылка на сторонний программный код или сам код. Является критичной уязвимостью, так как взломщик может выполнять свои скрипты на сервере или получить доступ к данным, хранимым у пользователя.
• SQL-инъекция
  Смысл: в параметр, определяющий SQL-запрос, передаётся данные, образующее запрос для доступа к закрытым данным. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в базе данных. Для изменения запроса взломщик может использовать следующие конструкции: SELECT, UNION, UPDATE, INSERT, OR, AND.
• Межсайтовый скриптинг или XSS
  Смысл: в параметр, определяющий выводимые пользователю данные, передаётся сторонний программный код. Является критичной уязвимостью, так как взломщик может получить конфиденциальные данные, хранимые в браузере клиента. Для изменения запроса взломщик использует html-теги.

Правила написания безопасного кода на PHP

• Блокирование вывода ошибок
  Для этого достаточно в программном коде задать error_reporting(0) или в файле .htaccess добавить строку php_flag error_reporting 0
• Использование сложных паролей для доступа к административным страницам
  Для этого достаточно использовать многозначные пароли, не имеющие семантического значения (например, К7O0iV98dq).
• Логирование критических действий пользователя
  Не обеспечивает защиту напрямую, но позволяет выявить взломщиков и определить уязвимости, которые они использовали. Для этого действия пользователя и переданные им данные, которые касаются критических моментов работы системы, достаточно записывать в обычный текстовый файл.

  Пример функции логирования и ее работы:
  

  function writelog($typelog, $log_text) {
  
    $log = fopen('logs/'.$typelog.'.txt','a+');
  
    fwrite($log, "$log_text\r\n");
  
    fclose($log);
  
  }
  
  writelog('authorization', date("y.m.d H:m:s")."\t".$_SERVER['REMOTE_ADDR']."\tУспешный вход");

• Закрытие доступа к модулям сайта
  Обеспечивает защиту от попыток просмотра их содержимого или выполнения. Для этого достаточно в файле .htaccess настроить доступ к файлам модулей при помощи конструкций FilesMatch и Files.
  Например, мы закрываем доступ ко всем модулям с расширением php, кроме файла capcha.php:

  Order Deny, Allow
  
  <FilesMatch "\.php">
  
   Deny from all
  
  </FilesMatch>
  
  <Files capcha.php>
  
   Allow from all
  
  </Files>

• Отключение возможности задания глобальных переменных
  Для этого достаточно в настройках сервера задать register_globals = off; или в файле .htaccess добавить строку php_flag register_globals off. Использование ini_set(‘register_globals’,0) проблему не решит, так как переменные задаются до начала выполнения скрипта.
• Отключение возможности использования удалённых файлов
  Для этого достаточно в настройках сервера задать allow_url_fopen = off. Это обеспечивает частичную защиту от PHP-инъекций, но не полную, так как взломщик может передавать не ссылку на файл с программным кодом, а сам программный код. Для полной защиты от PHP-инъекций необходимо дополнительно использовать фильтрацию поступивших данных. Иногда данную меру защиты невозможно использовать из-за особенностей работы проекта (нужно обращаться к удалённым файлам).
• Фильтрация поступающих данных
  Обеспечивает защиту от большинства уязвимостей. Универсального решения не существует. Желательно использовать проверку по «белому» списку символов в совокупности с проверкой на запрещённые слова. «Белым» называется список разрешённых символов. В этот список не должны входить опасные символы, например, <>. К запрещённым словам можно отнести: script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmp, а также html-теги. Пример фильтрации поступающих данных:
  

  // Проверка по белому списку. Допускаются только русские и латинские буквы, цифры и знаки _-
  
  if (preg_match("/[^(\w)|(\x7F-\xFF-)|(\s)]/",$text))
  
  {
  
    $text = '';
  
  }
  
  // Фильтрация опасных слов
  
  if (preg_match("/script|http|<|>|<|>|SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text))
  
  {
  
    $text = '';
  
  }

• Проверка на загрузку файла при помощи HTTP POST
  Обеспечивает защиту от PHP-инъекций через загрузку файлов. Для обеспечения этого загруженные на сервер файлы необходимо проверять функцией is_uploaded_file() или перемещать функцией move_uploaded_file(). Данный вид защиты можно не использовать, если отключена возможность задания глобальных переменных.
• Экранирование символов кавычек данных, передаваемых в базу данных
  Обеспечивает защиту от SQL-инъекций. Наиболее оптимальным методом является обработка всех поступивших не числовых данных с помощью функции mysql_real_escape_string(). Следует отметить, что использование данной функции требует наличие подключения к базе данных MySQL. Можно так же использовать автоматическое экранирование, поступающих данных. Для этого достаточно в файле .htaccess добавить строку php_value magic_quotes_gpc on, но этот способ не является надёжным, так как может привести к двойному экранированию. Пример экранирования кавычек с помощью функции mysql_real_escape_string():

  if (!is_numeric($text))
  
  {
  
    $textrequest = mysql_real_escape_string($text);
  
  } 

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

• Преобразование специальных символов в HTML-сущности перед выводом
  Обеспечивает защиту от XSS. Для этого данные, введённые пользователем, которые могут содержать нежелательные html-тэги, при выводе достаточно обработать функцией htmlspecialchars(). Данный вид защиты можно не использовать, если фильтрация поступающих данных отсеивает опасные HTML-тэги.

Заключение

Как видите, создание продуманной системы безопасности скриптов не такое трудоёмкое дело. Данный материал не претендует на роль руководства по безопасности скриптов, но я надеюсь, что он подтолкнет PHP-программистов использовать более продуманные методы защиты.