Должны ли выполняться подготовленные PHP PDO заявления?

На странице PDO :: Prepare говорится,

"и помогает предотвратить атаки SQL-инъекций, устраняя необходимость вручную указывать параметры"

Зная это, есть ли функция PHP, такая как mysql_real_escape_string (), которая заботится о том, чтобы избежать укусов для PDO? Или PDO заботится обо всех побегах для меня?

РЕДАКТИРОВАТЬ

Теперь я понимаю, что задал неправильный вопрос. Мой вопрос действительно был: «Что все делает PDO для меня?» Который я понимаю теперь с этими ответами, что это действительно только устраняет необходимость избежать цитат. Но мне все равно придется делать какие-либо другие вызовы для санации PHP для значений, которые я передаю функции execute. Такие, как htmlentities (), strip_tags () … и т. Д. …

PDO не выходит за переменные. Переменные и команда SQL передаются независимо через соединение MySQL. И токенизатор SQL (парсер) никогда не смотрит на значения . Значения просто копируются дословно в хранилище базы данных без возможности причинения какого-либо вреда. Вот почему нет необходимости сортировать данные с помощью подготовленных инструкций.

Обратите внимание, что это скорее преимущество скорости. С mysql_real_escape_string () вы сначала сортируете свои переменные в PHP, а затем отправляете на сервер неэффективную команду SQL, которая требует дорогостоящей частичной пересчеты фактической команды SQL из значений. Вот почему часто говорят, что преимущество безопасности является неявным, а не основной причиной использования PDO.

Если вы выполняете команду SQL и фактически не используете подготовленные статусы (не хорошо!), То да, есть еще функция escape для PDO: $ pdo-> quote ($ string)

Да и нет:

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

Очень немногие люди понимают, что такое побег и когда его использовать.
Убеждение в себе не делает данные «безопасными». он просто выходит из разделителей, чтобы отличить разделитель от части данных. field = 'it's me' вызовет ошибку, а field = 'it\'s me' не будет. Это единственная цель побега. Таким образом, он работает только при использовании котировок. Если вы этого не сделаете – побег станет бесполезным.

Используете ли вы кавычки с заполнителями? Нет. Таким образом, никакое спасение не было бы разумным.

Когда вы используете привязку, она работает совсем по-другому.
Он не отправляет весь запрос на сервер, а отправляет ваш подготовленный запрос отдельно от привязанных данных. Поэтому он не может вмешиваться. И, таким образом, инъекции невозможно.

Если вы готовите заявление и используете bindParam или bindValue для предоставления переменных, вам не нужно избегать переменных. Обратите внимание, что эти функции предполагают, что переменная содержит строку, поэтому используйте третий параметр для bindValue, если вы хотите использовать логические значения или float.

Вам не о чем беспокоиться. PDO не требует, чтобы вы удаляли свои данные, прежде чем передавать их в базу данных.

Изменить. Чтобы быть ясным, я хочу сказать, что до тех пор, пока вы передаете переменные в свои параметры (например, значение поля формы), вам не нужно беспокоиться об этом. Однако, если вы передаете переменные, которые вы определили как строки, например, то, очевидно, вам нужно избегать всего, что нужно экранировать в этой строке, чтобы избежать нарушения синтаксиса. Однако это даже не имеет особого смысла, поскольку одним из основных преимуществ PDO является то, что вы передаете информацию от пользователя в базу данных, не пытаясь самостоятельно ее дезинфицировать, и есть не так много раз (если есть?) что вы будете передавать строки, которые вы сами определили.

Кроме того, убедитесь, что вы все еще дезинфицируете свои данные для типа . Например, убедитесь, что это целое число, если вы ожидаете, что оно будет, убедитесь, что оно меньше или больше x, если вы ожидаете, что оно будет и т. Д.