Подготовленных инструкций/параметризованных запросов, как правило, достаточно для предотвращения внедрения 1-го порядка в эту инструкцию^*. Если вы используете непроверенный динамический sql где-либо еще в своем приложении, вы все еще уязвимы для инъекции 2-го порядка .

Внедрение 2-го порядка означает, что данные были циклически обработаны в базе данных один раз, прежде чем быть включенными в запрос, и их гораздо сложнее выполнить. АФАИК, вы почти никогда не видите реальных спроектированных атак 2-го порядка, как обычно злоумышленникам проще проникнуть в социальную сеть, но иногда возникают ошибки 2-го порядка из-за дополнительных доброкачественных символов ' или подобных.

Вы можете выполнить атаку с внедрением 2-го порядка, когда вы можете сохранить значение в базе данных, которая позже будет использоваться в качестве литерала в запросе. В качестве примера предположим, что вы вводите следующую информацию в качестве своего нового имени пользователя при создании учетной записи на веб-сайте (при условии, что для этого используется база данных MySQL вопрос):

' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '

Если нет других ограничений на имя пользователя, подготовленный оператор все равно будет следить за тем, чтобы приведенный выше встроенный запрос не выполнялся во время вставки, и правильно сохранит значение в базе данных. Однако представьте, что позже приложение извлекает ваше имя пользователя из базы данных и использует объединение строк, чтобы включить это значение в новый запрос. Вы можете увидеть чужой пароль. Поскольку первые несколько имен в таблице пользователей, как правило, являются администраторами, возможно, вы также только что отдали ферму. (Также обратите внимание: это еще одна причина не хранить пароли в обычном тексте!)

Таким образом, мы видим, что подготовленных операторов достаточно для одного запроса, но сами по себе они недостаточны для защиты от атак с использованием sql-инъекций во всем приложении, поскольку в них отсутствует механизм обеспечения того, чтобы весь доступ к базе данных в приложении использовал безопасный код. Тем не менее, используется как часть хорошего дизайна приложения - который может включать такие методы, как просмотр кода или статический анализ, или использование ORM, уровня данных или уровня сервиса, который ограничивает динамический sql - подготовленные заявления являются основным инструментом для решения проблемы внедрения Sql. Если вы следуете хорошим принципам проектирования приложений, таким как отделение доступа к данным от остальной части вашей программы, становится легко обеспечить соблюдение или аудит того, что каждый запрос правильно использует параметризацию. В этом случае sql-инъекция (как первая, так и второй порядок) полностью предотвращен.

_{^* Оказывается, что MySQL/PHP (хорошо, были) просто тупы в обработке параметров, когда задействованы широкие символы, и все еще существует редкий случай, описанный в другом высоко оцененном ответе здесь, который может позволить инъекции проскользнуть через параметризованный запрос.}

Нет, так бывает не всегда.

Это зависит от того, разрешаете ли вы размещать пользовательский ввод в самом запросе. Например:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

Будет уязвим для SQL-инъекций, и использование подготовленных инструкций в этом примере не будет работать, поскольку вводимые пользователем данные используются в качестве идентификатора, а не в качестве данных. Правильным ответом здесь было бы использовать какую-то фильтрацию/проверку, например:

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];
$allowedTables = array('users','admins','moderators');
if (!in_array($tableToUse,$allowedTables))    
 $tableToUse = 'users';

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

Примечание: вы не можете использовать PDO для привязки данных, которые выходят за рамки DDL (Определение данных Язык), т.е. это не работает:

$stmt = $dbh->prepare('SELECT * FROM foo ORDER BY :userSuppliedData');

Причина, по которой вышеуказанное не работает, заключается в том, что DESC и ASC не являются данными . PDO может экранироваться только для данных. Во-вторых, вы даже не можете поместить ' кавычки вокруг него. Единственный способ разрешить сортировку по выбору пользователя - вручную отфильтровать и проверить, что это либо DESC, либо ASC.

Да, этого достаточно. Способ, которым работают атаки типа инъекции, заключается в том, чтобы каким-то образом заставить интерпретатор (базу данных) оценить что-то, что должно было быть данными, как если бы это был код. Это возможно только в том случае, если вы смешиваете код и данные на одном носителе (например, при построении запроса в виде строки).

Параметризованные запросы работают, отправляя код и данные отдельно, поэтому никогда не удастся найти в этом дыру.

Вы все еще можете быть уязвимы для однако другие атаки инъекционного типа. Например, если вы используете данные на HTML-странице, вы можете подвергнуться атакам типа XSS.

Нет, этого недостаточно (в некоторых конкретных случаях)! По умолчанию PDO использует эмулированные подготовленные инструкции при использовании MySQL в качестве драйвера базы данных. Вы всегда должны отключать эмулируемые подготовленные инструкции при использовании MySQL и PDO:

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Еще одна вещь, которую всегда следует делать, это установить правильную кодировку базы данных:

$dbh = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');

Также смотрите этот связанный с этим вопрос: Как я могу предотвратить внедрение SQL в PHP?

Также обратите внимание, что это касается только стороны базы данных из того, за чем вам все равно придется следить при отображении данных. Например, снова используя htmlspecialchars() с правильной кодировкой и стилем цитирования.

Лично я бы всегда сначала выполнял некоторую очистку данных, так как вы никогда не можете доверять вводу данных пользователем, однако при использовании привязки заполнителей/параметров введенные данные отправляются на сервер отдельно в инструкцию sql, а затем связываются вместе. Ключевым моментом здесь является то, что это привязывает предоставленные данные к определенному типу и конкретному использованию и исключает любую возможность изменения логики инструкции SQL.

Eaven если вы собираетесь предотвратить внедрение sql-интерфейса, используя проверки html или js, вам следует учитывать, что проверки интерфейса "обходимы".

Вы можете отключить js или отредактировать шаблон с помощью интерфейсного инструмента разработки (встроенного в firefox или chrome в настоящее время).

Поэтому, чтобы предотвратить внедрение SQL, было бы правильно очистить серверную часть даты ввода внутри вашего контроллера.

Я хотел бы предложить вам использовать собственную функцию PHP filter_input() для того, чтобы для очистки получаемых и вводимых значений.

Если вы хотите обеспечить безопасность для разумных запросов к базе данных, я хотел бы предложить вам использовать регулярное выражение для проверки формата данных. preg_match() поможет вам в этом случае! Но будьте осторожны! Движок регулярных выражений не такой легкий. Используйте его только в случае необходимости, в противном случае производительность вашего приложения снизится.

Безопасность имеет свои издержки, но не тратьте впустую свою производительность!

Простой пример:

Если вы хотите дважды проверить, является ли значение, полученное от GET, - это число, меньшее 99 если(!preg_match('/[0-9]{1,2}/')){...} является более тяжелым из

if (isset($value) && intval($value)) <99) {...}

Итак, окончательный ответ: "Нет! Подготовленные операторы PDO не предотвращают все виды sql-инъекций"; Это не предотвращает неожиданные значения, просто неожиданную конкатенацию