PDO являются подготовленными операторами, достаточными для предотвращения Внедрения SQL?

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

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

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

Подготовленные операторы / параметризированные запросы вообще достаточны для предотвращения 1-я инжекция порядка на том операторе <глоток> * . При использовании неконтролируемого динамического sql где-нибудь еще в приложении, Вы все еще уязвимы для 2-я инжекция порядка .

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

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

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

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

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

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

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

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

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

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