2012-01-16 4 views
7

Согласно PHP документации PDO :: подготовить() добавляет кавычки для всех ваших параметров, так что вам не придется беспокоиться о делать это:Работа с цитатами добавленными PDO :: подготовить()

«Параметры для подготовленных операторов не нужно указывать, драйвер автоматически обрабатывает это. Если приложение использует исключительно подготовленные операторы, разработчик может быть уверен, что SQL-инъекция не произойдет (однако, если другие части запроса построенный с несвязанным вводом, SQL-инъекция по-прежнему возможна). "

Проблема с этим для меня заключается в том, как я строю свои запросы и структуру базы данных. Обычно часть FROM инструкции SQL необязательно должна быть параметризована, потому что таблица, вероятно, будет определяться прямым пользовательским вводом. Однако с моим кодом, который имеет место в некоторых местах, и, таким образом, я чувствую себя более комфортно с параметризованной версией.

SELECT * FROM ? WHERE ?=? 

в отличие от SELECT * FROM имя_таблицы WHERE? =?

Итак, мой вопрос заключается в том, можно ли допустить, чтобы мой объект PDO добавлял кавычки вокруг параметра FROM, чтобы я не получал SQL-ошибок, брошенных мне в лицо? Или я должен сделать это по-другому.

+2

В чем вопрос? – jeroen

+0

Это не обязательно добавляет кавычки. Драйверы, которые поддерживают встроенные подготовленные операторы, сохраняют литерал '?', А сервер базы данных выполняет подстановку. - Однако вам нужно объяснить, что конкретно делает ваш код, и почему здесь проблема. Добавление ''? ''Или'': placeholder'' в предложениях FROM - это литеральные строки, а не связанные параметры. – mario

+0

Извините, я случайно попал в enter, прежде чем я закончил набирать вопрос – hamalnamal

ответ

4

Заполнители в подготовленных операциях предназначены только для значений. Единственный способ вставить динамические имена таблиц - сделать это самостоятельно

"SELECT FROM `".$table."` WHERE `".$column."` = ?" 
+3

И, конечно, просто обертывание значения с помощью обратных тиков не является безопасным, если содержимое переменной происходит из испорченного источника. – Matthew

+0

@YourCommonSense Можете ли вы дать мне прецедент, где имена _table_ и _column_ происходят из источника из вашего контроля? Когда они _somehow_ основываются на пользовательском вводе, гораздо проще просто предоставить им свой DB-пароль. Это говорит о том, что вы можете предположить, что они происходят из надежного источника (например, конфигурации или жестко закодированы где-то в другом месте), или вы сделали что-то очень неправильное. И это все еще не мешает вам использовать ваш мозг :) – KingCrunch

+0

Дешевый разговор, чувак. –

2

@KingCrunch в основном правильный в его ответе. Вы должны действительно избежать строки самостоятельно. Нечто подобное должно защищать от большинства инъекций:

//make sure $table and $column only contain alphanumeric chars 
$table = preg_replace("/[^A-Za-z0-9]/", '', $table); 
$column = preg_replace("/[^A-Za-z0-9]/", '', $column); 

$query = "SELECT FROM `{$table}` WHERE `{$column}` = ?" 
Смежные вопросы