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

инъекция 2-го порядка означает, что данные были циклически через базу данных один раз, прежде чем быть включенными в запрос, и намного сложнее снять. AFAIK, вы почти никогда не видите real engineered Атаки 2-го порядка, так как обычно атакующим легче социализировать свой путь, но иногда у вас возникают ошибки 2-го порядка из-за дополнительных доброкачественных ' символы или подобные.

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

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

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

мы видим, что подготовленных операторов достаточно для одного запроса, но сами по себе они не достаточно для защиты от атак SQL-инъекций во всем приложении, потому что у них нет механизма для обеспечения того, чтобы весь доступ к базе данных в приложении использовал безопасный код. Однако, использованный как часть хорошего дизайн приложения-который может включать в себя такие методы, как обзор кода или статический анализ, или использование ORM, слоя данных или уровня сервиса, который ограничивает динамический sql - подготовленные заявления are основной инструмент для решения проблемы 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-инъекцию front-end, используя проверки html или js, вам придется учитывать, что проверки front-end "обходимы".

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

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

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

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

безопасность имеет затраты, но не тратьте впустую свою производительность!

легко пример:

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

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

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