Безопасно ли привязка oci по имени предотвращает внедрение SQL-кода?
Я прочитал документацию, предоставленную oracle здесь , где говорится, что:
Binding is important for Oracle database performance and also as a way to avoid SQL Injection security issues.
Насколько безопасно использовать oci_bind_by_name для экранирования переменных? Существуют ли лучшие методы, позволяющие избежать внедрения SQL, или oci_bind_by_name достаточно?
ТИА!
1 answers
В обычных случаях достаточно использовать привязанные параметры, и это хорошая практика для предотвращения внедрения SQL.
Но параметр в подготовленном операторе может использоваться только для значения в выражении SQL. Другими словами, там, где вы обычно пишете строковый литерал в кавычках, литерал даты в кавычках или числовой литерал. И один параметр == одно значение (без списков).
Вы должны использовать привязанные параметры для этих случаев. Если вы задаете этот вопрос, потому что вы подумайте, что вы, возможно, захотите пропустить использование связанных параметров, если кто-то ответит, что их недостаточно, тогда извините, вы не будете освобождены от практики безопасного программирования.
Однако существуют и другие (возможно, менее распространенные) случаи, для которых связанные параметры не работают. Если вам нужно написать запрос с именем динамической таблицы, именем столбца или другим идентификатором, или целым выражением, или ключевым словом SQL, то вам нужен другой метод. Эти случаи должны быть исправлены в синтаксисе SQL по адресу подготовьте время, чтобы их нельзя было параметризовать.
Например, вот запрос с динамическими частями, обозначаемыми с помощью переменных, которые не могут быть параметрами:
$sql = "SELECT * FROM mytable ORDER BY $column_of_users_choice $asc_or_desc";
Вы должны использовать белый список для этих случаев. Другими словами, убедитесь, что строка, которую вы интерполируете в свой запрос в качестве имени динамической таблицы, на самом деле является одной из таблиц, существующих в вашей базе данных. Убедитесь, что ключевые слова SQL являются допустимыми ключевыми словами.
Никогда не принимайте пользователя введите дословно и интерполируйте его в SQL (или любой другой код, который анализируется во время выполнения, например аргумент, который вы передаете eval() или shellexec()). И не только пользовательский ввод может быть небезопасным контентом.
Смотрите также мою презентацию Мифы и заблуждения о внедрении SQL для получения дополнительных объяснений.