Техника защиты. 
Безопасность базы данных

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

Большинство атак построены на использовании кода, который писался без учета соображений безопасности. Никогда не доверяйте введенным данным, особенно если они идут с клиентской стороны, пусть даже и из поля отметки, скрытого поля или записи cookie. Первый пример показывает, к чему может привести подмена этих данных.

Никогда не соединяйтесь с базой данных в роли суперпользователя или владельца. Всегда используйте специальных пользователей с минимумом прав.

Проверяйте ввод на совпадение типа данных с требуемым. PHP включает в себя большое количество проверочных функций, от самых простейших из разделов «Функции для работы с переменными» и «Функции обработки символьного типа», (к примеру is_numeric () и ctype_digit () соответственно) до регулярных выражений Perl («Регулярные выражения, совместимые с Perl»).

Если программа ожидает число, проверяйте данные с помощью is_numeric (), или просто изменяйте тип с помощью settype (), или даже используйте численное представление, выданное sprintf ().

Пример: Более безопасная разбивка на страницы.

settype ($offset, 'integer');

$query = «SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;» ;

// отметим %d в строке форматирования, использование %s бесполезно.

$query = sprintf («SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;» ,.

$offset);

Необходимо предварять любой нечисловой ввод, передаваемый в базу данных, функциями addslashes () или addcslashes (). В первом примере показано, что кавычек в статической части запроса недостаточно.

Нельзя выводить никакой информации о структуре базы данных ни коим образом.

Можно использовать хранимые процедуры и заданные расположения для того, чтобы отвязать обращение к данным от программы так, чтобы пользователи не имели прямого доступа к таблицам и представлениям, но этот вариант имеет собственные проблемы.

Кроме того, необходимо вести журнал операций в программе или собственно в базе данных, если это поддерживается. Ведение журнала не предотвратит внедрения, но оно поможет определить, какая часть программы была поставлена под удар. Сам журнал бесполезен — полезна хранимая в нем информация. Чем ее больше — тем лучше.