Достаточно ли подготовленных операторов PDO для предотвращения SQL-инъекции?

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

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

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

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

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

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

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

_{^*It turns out that MySql/PHP are (okay, were) just dumb about handling parameters when wide characters are involved, and there is still a rare case outlined in the other highly-voted answer here that can allow injection to slip through a parameterized query.}

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

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

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

Нет, не всегда.

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

$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.

Нет, этого недостаточно (в некоторых конкретных случаях)! По умолчанию 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() с правильным стилем кодирования и цитирования.

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

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

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

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

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

За безопасность приходится платить, но не тратьте зря свои результаты!

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

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

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

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