Прежде чем кто-либо скачет к выводам относительно характера этого вопроса, я уже знаю о параметризованных / подготовленных заявлениях и использую их по возможности. К сожалению, не всегда можно использовать их при построении динамических запросов.
Я заинтересован в работе с базами данных, отличными от MySQL, но я не могу легко найти хорошие источники о том, как избежать строк для каждого расширения базы данных, чтобы предотвратить SQL Injection .
В документах PHP перечислены следующие расширения базы данных конкретного поставщика. Я смел тем, кого меня больше всего интересуют:
Пример динамического запроса, который не работает для большинства параметризованных операторов:
"Select $col1, $col2 from $table where $col1 = ?" После того как $col1 , $col2 и $table были экранированы, оператор можно использовать в подготовленном сообщении.
PostgreSQL может использовать pg_escape_string для стирания строки.
Для PostgreSQL вам не нужно ускользать благодаря pg_query_params()
Кроме того, вы должны использовать PDO с подготовленными операторами . Они заботятся об этом, и вы можете передавать аргументы отдельно; как и pg_query_params()
В MongoDB вы не пишете SQL, а работаете с объектами («документы») – вам не нужно избегать вещей, поскольку вы никогда не используете строки, кроме данных.
Однако вам необходимо убедиться, что вы фактически передаете строки, а не массивы в API MongoDB. По крайней мере, в PHP, проходящем массив, такой как array('$ne' => 1) будет выполняться проверка != 1 и, таким образом, будет так же опасна, как SQL-инъекция. И, к сожалению, PHP позволяет клиенту создавать массивы внутри $_POST и т. Д., Просто предоставляя поле с именем, используя синтаксис массива PHP, такой как password[$ne] . [Источник]
Используйте mysql_real_escape_string .
Используйте mysqli_real_escape_string .
Насколько я могу судить:
function oci_escape_string( $str ) { return strtr( $str, array( "'" => "''" ) ); }
Должен делать трюк , игнорируя символы подстановочных знаков для предложений LIKE.
Согласно его руководству, CUBRID PHP API имеет тот же синтаксис, что и MySQL, т.е. cubrid_real_escape_string . С его новой версией CUBRID 8.4.0 она обеспечивает 90% совместимость с MySQL.