Базы данных — главные компоненты большей части веб-приложений, которые помогают сайтам создавать динамическое содержание. Нужно серьёзно относиться к защите баз данных, поскольку в базах данных хранится конфиденциальная или секретная информация. Чтобы получить или сохранить информацию, необходимо подключиться к базе данных, отправить законный запрос, получить результат и закрыть соединение. Наиболее распространённый язык запросов в таком взаимодействии — язык структурированных запросов SQL. Подробнее о подделке SQL-запросов рассказывает раздел «SQL-инъекции». Нетрудно догадаться, что сам PHP не защищает базу данных. Этот раздел документации вводит основы безопасного доступа и управления базами данных в PHP-скриптах. Требуется помнить простое правило: глубокая защита. Чем шире меры по защите базы данных, тем меньше вероятность того, что злоумышленник раскроет или злоупотребит сохранённой информацией. Хороший проект структуры базы данных и приложения помогает справиться с опасениями. Первый шаг — создать базу данных или выбрать готовую БД, которую предоставила третья сторона. При этом БД назначается владельцу, который выполнил запрос, который создал базу данных. Обычно только владельцу или суперпользователю разрешается выполнять действия с объектами в базе данных, а чтобы разрешить эти действия другим пользователям, пользователей наделяют привилегиями. Приложения не должны подключаться к базе данных через учётную запись владельца или суперпользователя, потому что у этих пользователей есть права на выполнение произвольного запроса, например, на изменение схемы БД (например, удаление таблиц) или удаление всего содержимого структуры БД. Пользователей БД разрешается создавать для каждой отдельной задачи приложения и ограничивать права пользователей на действия с объектами базы данных. Пользователю назначают только те привилегии, которые требуются для конкретных задач, и избегают ситуаций, при которых у одного и того же пользователя есть чрезмерные права на взаимодействие с базой данных. Тогда, если злоумышленники получат доступ к БД через учётные данные приложения, у злоумышленников будут права на изменение только тех данных, которые изменяло приложение. Возможно, для повышения безопасности потребуется устанавливать соединения по SSL-протоколу, чтобы зашифровать сообщения между клиентом и сервером, или подключаться по SSH-протоколу, чтобы зашифровать сетевое соединение между клиентами и сервером базы данных. Каждый из этих способов связи затруднит злоумышленнику отслеживание трафика и получение информации о базе данных. Протоколы SSL и SSH защищают данные, которые передаются от клиента к серверу: эти протоколы не защищают постоянные данные, которые хранятся в базе данных. Протокол SSL — протокол шифрования на уровне сеанса передачи данных. Злоумышленник сможет раскрыть или использовать конфиденциальные данные не по назначению, как только получит прямой (в обход веб-сервера) доступ к базе данных, если только база данных не защищает информацию. Шифрование данных снижает риск угрозы, но немногие базы данных предлагают такой тип шифрования данных. Простейший способ защитить информацию — вначале установить пакет для шифрования данных, а затем использовать этот пакет в PHP-скриптах. PHP помогает в этом и предлагает модули вроде OpenSSL и Sodium, которые покрывают широкий круг алгоритмов шифрования. Скрипт шифрует данные перед вставкой в базу данных и расшифровывает данные при извлечении. В следующих параграфах документация приводит примеры шифрования. При работе со скрытыми данными, которые требуют повышенного внимания, данные хешируют, если не требуется необработанное представление данных, — то, которое не требуется показывать. Популярный пример данных, которые требуют хеширования, — хранение криптографического хеша пароля в БД вместо хранения самого пароля. Функции, которые работают с паролями, помогают удобно хешировать конфиденциальные данные и работать с этими хешами. Функция password_hash хеширует заданную строку самым стойким из доступных алгоритмом, а функция password_verify проверяет, совпадает ли заданный пароль с хешем, который хранится в базе данных. ]]> SQL-инъекция — техника, при которой злоумышленник пользуется недостатками в коде приложения, который отвечает за построение динамических SQL-запросов. Злоумышленник получает доступ к привилегированным разделам приложения, получает информацию из базы данных, подменяет данные или даже выполняет опасные команды системного уровня на узле базы данных. Уязвимость возникает, когда разработчики конкатенируют или интерполируют произвольные входные данные в SQL-запросах. В следующем примере пользовательский ввод интерполируется в SQL-запрос, что помогает злоумышленнику получить учётную запись суперпользователя в базе данных. ]]> В стандартном сценарии пользователи нажимают на ссылки «Вперёд» и «Назад», в URL-адресах которых закодировано смещение, значение которого получает переменная $offset. Скрипт ожидает, что входящее значение для переменной $offset — число. Однако, что если взломщик выполнит попытку взломать систему и добавит к URL-адресу следующее значение: Если бы это случилось, скрипт предоставил бы злоумышленнику доступ суперпользователя. Обратите внимание, что значение 0; записали, чтобы передать правильное смещение для исходного запроса и завершить запрос. Распространённый приём, который заставляет SQL-парсер игнорировать остальную часть запроса разработчика, — последовательность символов --, которая играет в SQL роль синтаксиса комментариев. Ещё один способ раскрыть пароли учётных записей в БД — атаковать страницы с результатами поиска. Злоумышленнику требуется только проверить, есть ли в запросе к серверу переменные, которые попадут в SQL-запрос и которые не обрабатываются правильно. Эти фильтры обычно устанавливают в форме перед выполнением поиска, чтобы изменить поведение условий WHERE, ORDER BY, LIMIT и OFFSET в запросе SELECT. Если база данных поддерживает конструкцию UNION, злоумышленник попробует добавить к оригинальному запросу ещё один, чтобы вывести список паролей из произвольной таблицы. Настоятельно рекомендуется хранить только зашифрованные пароли. ]]> Статическую часть запроса комбинируют с другим SELECT-запросом, который раскроет все пароли: Инструкции UPDATE и INSERT также подвержены таким атакам. ]]> Если злоумышленник отправляет значение ' or uid like'%admin%' для переменной $uid, чтобы изменить пароль администратора, или просто присваивает переменной $pwd значение hehehe', trusted=100, admin='yes, чтобы получить дополнительные привилегии, тогда запросы переплетаются: ]]> Хотя остаётся ясным, что для успешной атаки злоумышленнику нужны хотя бы частичные знания об архитектуре базы данных, эту информацию часто получают легко. Например, когда код — часть открытого программного обеспечения и лежит в открытом доступе. Информация также раскрывается и закрытым исходным кодом, даже если код закодировали, обфусцировали или скомпилировали, и даже собственным кодом через отображение сообщений об ошибках. Другие методы включают подстановку типичных имён таблиц и столбцов: форма входа в систему, которая использует таблицу users с именами столбцов id, username и password. Страшный пример получения доступа к командам уровня операционной системы на отдельных хостах баз данных. ]]> Если злоумышленник отправит значение a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- для переменной $prod, то переменная $query будет равна: ]]> MSSQL Server выполняет пакетные SQL-запросы, включая команду для добавления нового пользователя в базу данных локальных учётных записей. Если бы это приложение запустили от имени суперадминистратора sa, а службу MSSQLSERVER запустили бы с достаточными привилегиями, у злоумышленника появилась бы учётная запись с доступом к локальной машине. Часть приведённых примеров привязана к конкретному серверу базы данных, но это не говорит о невозможности похожей атаки на другие продукты. Сервер базы данных подвержен и другим уязвимостям. Забавный пример проблем, связанных с SQL-инъекциями Изображение любезно предоставил сайт веб-комиксов xkcd Рекомендуемый способ избежать SQL-инъекций — связать данные подготовленными инструкциями. Параметризованных запросов недостаточно, чтобы на 100 процентов избежать внедрения SQL-инъекций, но это простейший и безопасный способ передать входные данные SQL-инструкциям. Литералы динамических данных в условиях WHERE, SET и VALUES требуется заменить заполнителями. Сервер базы данных свяжет фактические данные при выполнении и отправит отдельно от SQL-команды. Сервер применяет связывание параметров только для данных. Другие динамические части SQL-запроса требуется отфильтровать по известному списку разрешённых значений. prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}"); // Значение передаётся с подстановочными знаками LIKE $stmt->execute(["%{$productId}%"]); ?> ]]> Подготовленные инструкции предоставляют модули PDO, MySQLi и другие библиотеки баз данных. Атаки с внедрением SQL-инъекций обычно основаны на коде, который написали без учёта требований безопасности. Разработчик не должен доверять никаким входным данным, особенно со стороны клиента, даже если входные значения поступают из HTML-блока SELECT, скрытого поля ввода или из cookie. Первый пример показывает, что такой простой запрос легко приводит к катастрофе. Стратегия глубокой защиты включает набор практик хорошего кода: Не подключайтесь к базе данных как суперпользователь или владелец базы данных. Используйте только пользователей с минимальными привилегиями. Проверяйте входные данные на соответствие типу, который ожидался. В PHP содержится много функции для проверки входных данных, от простейших функций для работы с переменными наподобие функции is_numeric и функций проверки типа символов наподобие функции ctype_digit и далее к поддержке Perl-совместимых регулярных выражений. Если приложение ожидает числовые входные данные, рассмотрите применимость проверки данных функцией ctype_digit, незаметно измените тип входных данных функцией settype или получите числовое представление входных данных функцией sprintf. Если на уровне базы данных не поддерживается связывание переменных, возьмите в кавычки каждое пользовательское нечисловое значение, которое передаётся в БД через характерную для конкретной базы данных функцию экранирования строки: mysql_real_escape_string, sqlite_escape_string и т. д. Общие функции наподобие addslashes полезны только в конкретных средах (например, СУБД MySQL в однобайтовой кодировке с отключённым режимом NO_BACKSLASH_ESCAPES), поэтому при работе с БД лучше избегать таких функций. Ни в каком случае не выводите информации о БД, особенно о структуре. Дополнительную информацию дают разделы «Сообщения об ошибках» и «Функции обработки и логирования ошибок». Кроме сказанного, выгоду получают от логирования запросов либо внутри скрипта, либо на уровне базы данных, если БД поддерживает логирование. Очевидно, логирование не в состоянии предотвратить попытки навредить, но полезно при трассировке приложения, защиту которого получилось обойти. Польза файла журнала заключается не в самом файле, а в информации, которую содержит лог. Недостатку информации лучше предпочесть избыточное логирование.