В чем разница между двумя типами подготовленных заявлений?эмулированные подготовленные заявления против реальных подготовленных заявлений
Я думаю, что реальное подготовленные заявления требуют сторона сервера поддержка которым принимает Paramenters после разбора и составления схемы/шаблонов SQL коды, и, я полагаю, это то, что гарантирует нас от SQL-инъекций.
В случае эмулируемых подготовленных отчетов без поддержки сервера, что
гарантирует нам это?
Вы правы, настоящие подготовленные операторы должны поддерживаться сервером. Реальное готовое средство запрашивает базу данных в два этапа.
Первый шаг состоит в отправке шаблона запроса, который сервер может предварительно скомпилировать. Механизм базы данных также заранее подготовляет план выполнения (в основном, какие индексы будут использоваться для обслуживания реального запроса).
Второй шаг - предоставить фактические значения заполнителям и выполнить фактический запрос с этими параметрами.
Обычно это позволяет ускорить выполнение нескольких похожих запросов, поскольку 1. запрос уже был предварительно скомпилирован (план выполнения уже вычислен) и 2. после этого будут отправлены только значения параметров.
Эмулируемый запрос - это просто синтаксический сахар, который позволяет упростить отправку (не более быстрое выполнение) нескольких последовательных похожих запросов. Полные инструкции SQL отправляются на сервер каждый раз, когда выполняется эмулированный запрос.
Когда сервер не поддерживает реальные подготовленные операторы, рекомендуется использовать эмулированные подготовленные операторы, поскольку драйвер по-прежнему заботится об экранировании значений для вас, что делает SQL-инъекцию менее вероятной.
В случае эмулируемых подготовленных заявлений без поддержки сервера, что означает , он гарантирует нам противодействие этому?
Это хороший вопрос.
По иронии судьбы, тот же механизм, что и с родными подготовленными операциями, в некотором роде.
Основная идея подготовленного заявления, чтобы сделать данные буквенные обработана должным образом и сделать такую обработку неизбежной. Хотя детали такой обработки не так важны.
Основная проблема с SQL-инъекцией заключается в том, что она не существует сама по себе. Вся «опасность» исходит из неверно отформатированного запроса. Каждый раз, когда вы видите инъекционный случай, вы найдете неправильный форматированный литерал в качестве причины.
Хотя правильно отформатированный запрос уже защищен.
Вот почему нужно вообще не заниматься инъекциями, а только при правильном форматировании.
Так подготовленный оператор делает такое форматирование, так или иначе.
Вот и все.
, пожалуйста, помогите мне прояснить еще один момент, вы имеете в виду, что с эмулированным ps объявлением, где опасности в коде могут находиться и отделять его от безопасного кода, позволяет анти-sql-инъекции процедуры фильтровать эти части опасности должным образом, чтобы мы были гарантированы? – GionJh
нет «опасных» частей, и, следовательно, ничего не нужно фильтровать. –
Основная идея подготовленных заявлений - эффективность в случаях, когда несколько операторов различаются только при использовании разных значений буквального значения. В таких случаях оператор нужно анализировать только один раз и может выполняться несколько раз с разными значениями. Защита от SQL-инъекций является лишь побочным эффектом, поскольку подготовленный оператор и значения отделены друг от друга. Тем не менее, вы все еще можете иметь инъекции SQL при включении пользовательских значений в формулировку, которая должна быть подготовлена (происходит слишком часто). – Gumbo
Не называйте это «обычно быстрее». Разница может быть едва заметной для многих типов запросов. Не говоря уже о том, что во многих приложениях у вас просто нет возможности запустить его дважды. –
Итак, в случае реальных подготовленных утверждений мы гарантированы от инъекций, в то время как в случае эмулированных функций, которые мы используем, будут стараться изо всех сил защищать символы безопасно, так ли это? – GionJh
@ user986437 в случае эмулируемых мы также гарантируем –