Топ 7 ошибок безопасности PHP

Уязвимости SQL-инъекций

Уязвимости SQL-инъекций — еще один класс недостатков проверки входных данных. В частности, они позволяют использовать запрос к базе данных. Например, в вашем сценарии PHP вы можете запросить у пользователя идентификатор пользователя и пароль, а затем проверить пользователя, передав запрос в базу данных и проверив результат.

SELECT * FROM users WHERE name='$username' AND pass='$password'; 

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

 ' OR '1'='1 

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

 SELECT * FROM users WHERE name='known_user' AND pass='' OR '1'='1'; 

Это вернет имя пользователя без подтверждения пароля — злоумышленник получил доступ к вашему приложению как пользователь по своему выбору. Чтобы решить эту проблему, вам необходимо экранировать опасные символы из значений, переданных пользователем, в особенности одиночные кавычки (‘). Самый простой способ сделать это — использовать функцию PHP addslashes() .

 $username = addslashes($_POST["username"]);  $password = addslashes($_POST["password"]); 

Но в зависимости от вашей конфигурации PHP, это может быть необязательно! В большинстве версий PHP функция многозначительных магических цитат в PHP включена по умолчанию. Эта функция, которую можно отключить, установив для переменной magic_quotes_gpc php.ini значение « Off , Автоматически применяет addslashes ко всем значениям, отправляемым с помощью GET, POST или файлов cookie. Эта функция защищает от неопытных разработчиков, которые в противном случае могли бы оставить дыры в безопасности, подобные описанной выше, но это оказывает неблагоприятное влияние на производительность, когда входные значения не нужно экранировать для использования в запросах к базе данных. Таким образом, большинство опытных разработчиков решили отключить эту функцию.

Если вы разрабатываете программное обеспечение, которое может быть установлено на общих серверах, где вы, возможно, не сможете изменить файл php.ini , используйте код, чтобы проверить этот статус magic_quotes_gpc и, если он включен, пропустить все входные значения через stripslashes() PHP stripslashes() функция. Затем вы можете применить addslashes() к любым значениям, предназначенным для использования в запросах к базе данных, как обычно.

 if (get_magic_quotes_gpc()){  $_GET = array_map('stripslashes', $_GET);  $_POST = array_map('stripslashes', $_POST);  $_COOKIE = array_map('stripslashes', $_COOKIE);  } 

Недостатки SQL-инъекций не всегда приводят к повышению привилегий. Например, они могут позволить злоумышленнику выводить выбранные записи базы данных, если результат запроса будет напечатан в ваш вывод HTML.

Вы должны всегда проверять предоставленные пользователем данные, которые будут использоваться в запросе для символов '",;() и, возможно, для ключевых слов "FROM" , "LIKE" и "WHERE" без учета регистра. Это символы и ключевые слова, которые полезны при атаке с вставкой SQL, поэтому если вы удалите их из пользовательских вводов, в которых они не нужны, у вас будет гораздо меньше поводов для беспокойства из-за этого недостатка.

Отчет об ошибках

Вы должны убедиться, что значение php.ini для display_errors установлено в «0». В противном случае любые ошибки, встречающиеся в вашем коде, такие как ошибки подключения к базе данных, будут выводиться в браузер конечного пользователя. Злоумышленник может использовать этот недостаток для получения информации о внутренней работе вашего приложения, просто предоставляя неверный ввод и читая сообщения об ошибках, которые в результате.

Значение display_errors может быть установлено во время выполнения с помощью функции ini_set , но это не так желательно, как установка его в INI-файле, поскольку фатальная ошибка компиляции вашего скрипта все равно будет отображаться: если скрипт имеет фатальную ошибку и не может быть запущен функция ini_set не запускается.

Вместо отображения ошибок установите переменную error_log ini в значение «1» и часто проверяйте журнал ошибок PHP на наличие ошибок. Кроме того, вы можете разработать свои собственные функции обработки ошибок, которые автоматически вызываются, когда PHP обнаруживает ошибку, и могут отправлять вам электронные письма или выполнять другой код PHP по вашему выбору. Это разумная мера предосторожности, поскольку вы будете уведомлены об ошибке и исправите ее, возможно, еще до того, как злоумышленники узнают, что проблема существует. Прочтите справочные страницы PHP по обработке ошибок и узнайте о функции set_error_handler() .

Ошибки обработки данных

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

Наиболее распространенный тип ошибки обработки данных — незашифрованная передача конфиденциальных данных по протоколу HTTP, которые должны передаваться по протоколу HTTPS. Номера кредитных карт и информация о клиентах являются наиболее распространенными типами защищенных данных, но если вы передаете имена пользователей и пароли по обычному HTTP-соединению, а эти имена пользователей и пароли предоставляют доступ к конфиденциальным материалам, вы можете также передать сам чувствительный материал через незашифрованное соединение. Используйте безопасность SSL всякий раз, когда вы передаете конфиденциальные данные из вашего приложения в браузер пользователя. В противном случае злонамеренный перехватчик на любом маршрутизаторе между вашим сервером и конечным пользователем может очень легко перехватить конфиденциальную информацию из сетевых пакетов.

Такой же тип риска может возникнуть при обновлении приложений с использованием FTP, который является небезопасным протоколом. Передача файла PHP, содержащего пароли базы данных, на удаленный веб-сервер по небезопасному протоколу, такому как FTP, может позволить перехватчику перехватывать пакеты и раскрывать ваш пароль. Всегда используйте безопасный протокол, такой как SFTP или SCP, для передачи конфиденциальных файлов. Никогда не разрешайте отправку конфиденциальной информации вашим приложением по электронной почте. Сообщение электронной почты доступно для чтения любому, кто способен читать сетевой трафик. Хорошее практическое правило заключается в том, что если вы не напишите информацию на обратной стороне открытки и не отправите ее по почте, вам также не следует отправлять ее по электронной почте. Вероятность того, что кто-то действительно перехватит сообщение, может быть низкой, но зачем рисковать?