6.1.7 Client Programming Security Guidelines — MySQL 5.7

6.1.7 Безопасные рекомендации по программированию клиента

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

Обработка внешних данных надлежащим образом

Приложения, которые обращаются к MySQL, не должны доверять данным, вводимым пользователями, которые могут попытаться обмануть ваш код, вводя специальные или экранированные последовательности символов в веб-формы, URL-адреса или любые другие созданные вами приложения. Убедитесь, что ваше приложение остается безопасным, если пользователь пытается выполнить SQL-инъекцию, введя что-то вроде ; DROP DATABASE mysql; в форму. Это крайний пример, но крупные утечки безопасности и потеря данных могут произойти в результате использования хакерами аналогичных техник, если вы не подготовитесь к ним.

Распространённой ошибкой является защита только строковых значений данных. Не забудьте проверить также числовые данные. Если приложение генерирует запрос, такой как SELECT * FROM table WHERE ID=234, когда пользователь вводит значение 234, пользователь может ввести значение 234 OR 1=1, чтобы заставить приложение сгенерировать запрос SELECT * FROM table WHERE ID=234 OR 1=1. В результате сервер извлекает все строки таблицы. Это раскрывает каждую строку и приводит к чрезмерной нагрузке на сервер. Самый простой способ защиты от этого типа атаки — использовать одинарные кавычки вокруг числовых констант: SELECT * FROM table WHERE ID='234'. Если пользователь вводит дополнительную информацию, она вся становится частью строки. В числовом контексте MySQL автоматически преобразует эту строку в число и удаляет все заключительные нечисловые символы из неё.

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

Список проверок:

Включите строгий режим SQL, чтобы сообщить серверу быть более жёстким в отношении принимаемых значений данных. Смотрите Раздел 5.1.10, «Режим SQL сервера».
Попробуйте ввести одинарные и двойные кавычки (' и ") во все ваши веб-формы. Если вы получите какой-либо вид ошибки MySQL, незамедлительно исследуйте проблему.
Попробуйте изменить динамические URL-адреса, добавив %22 ("), %23 (#) и %27 (') к ним.
Попробуйте изменить типы данных в динамических URL-адресах с числовых на строковые, используя символы, показанные в предыдущих примерах. Ваше приложение должно быть защищено от этих и аналогичных атак.
Попробуйте ввести символы, пробелы и специальные символы вместо чисел в числовые поля. Ваше приложение должно удалить их перед передачей их MySQL или же сгенерировать ошибку. Передача не проверенных значений в MySQL очень опасно!
Проверяйте размер данных перед передачей их в MySQL.
Подключайте ваше приложение к базе данных с использованием имени пользователя, отличного от того, который вы используете для административных целей. Не предоставляйте вашим приложениям никаких разрешений доступа, которые им не нужны.

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

MySQL SQL-запросы: Используйте подготовленные SQL-запросы и принимайте значения данных только посредством заполнитель; см. Раздел 13.5, «Подготовленные запросы».
MySQL C API: Используйте вызов API . В качестве альтернативы используйте интерфейс подготовленных запросов C API и принимайте значения данных только посредством заполнитель; см. .
MySQL++: Используйте модификаторы escape и quote для потоков запросов.
PHP: Используйте либо расширения mysqli или pdo_mysql, а не устаревшее расширение ext/mysql. Предпочтительные API поддерживают улучшенный протокол аутентификации MySQL и паролей, а также подготовленные запросы с заполнителями. Смотрите также .

Если необходимо использовать устаревшее расширение ext/mysql, то для экранирования используйте функцию , а не или addslashes(), потому что только чувствительна к кодировке символов; другие функции могут быть “обходными” при использовании (неверных) многобайтовых наборов символов.
Perl DBI: Используйте заполнители или метод quote().
Java JDBC: Используйте объект PreparedStatement и заполнители.

Другие интерфейсы программирования могут иметь аналогичные возможности.

Надлежащая обработка сообщений об ошибках MySQL

Приложение отвечает за перехват ошибок, возникающих в результате выполнения SQL-запросов с сервером базы данных MySQL, и их надлежащую обработку.

Информация, возвращаемая в сообщении об ошибке MySQL, не является излишней, поскольку она является ключевой при отладке MySQL с помощью приложений. Например, практически невозможно отладить обычный запрос с 10-кратным объединением SELECT, не имея информации о том, какие базы данных, таблицы и другие объекты участвуют в проблемах. Таким образом, сообщения об ошибках MySQL порой должны обязательно содержать ссылки на имена этих объектов.

Простой, но небезопасный подход для приложения, когда оно получает такую ошибку от MySQL, заключается в перехвате её и отображении её дословно клиенту. Однако, раскрытие информации об ошибках — известный тип уязвимостей приложений (CWE-209), и разработчик приложения должен убедиться, что приложение не имеет этой уязвимости.

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

ERROR 1146 (42S02): Table 'mydb.mytable' does not exist

Вместо этого правильным поведением приложения при получении такой ошибки от MySQL является регистрация соответствующей информации, включая информацию об ошибке, в защищённом месте аудита, доступном только авторизованному персоналу. Приложение может вернуть что-то более общее, например, “Внутренняя ошибка” пользователю.