Является ли излишним использование подготовленных заявлений для привязки заполнителей в одиночку?

Question

A знаю много людей, которые используют готовые утверждения, только для привязки заполнителя.То есть они не собираются выдавать одно и то же утверждение более одного раза с разными значениями.Они просто считают, что использование PS таким способом более безопасно.

В моем понимании PS MySQL заключается в том, что SQL отправляется в виде одной передачи, за которой следует одна или несколько передач для отправки значений.Таким образом, использование PS для одного запроса менее эффективно, чем использование простого запроса, который выполняется за одну передачу.

Взвешивают ли преимущества безопасности, предлагаемые PS, потерю эффективности?Я так не думаю, потому что я не думаю, что это так сложно правильно экранировать значения, прежде чем добавлять их в ваш SQL.

Что вы думаете?

Answer 1

Подготовленный оператор компилируется и сохраняется в СУБД.Эти операторы могут быть кэшированы и использованы повторно.

Представьте себе преимущества при многократном обращении к одной и той же странице.

Кроме того, некоторые ядра СУБД (например, Oracle) могут устанавливать жесткие ограничения на операторы и доверять мне(Я знаю из опыта), вы не хотите исчерпать это.

Answer 2

Do the security benefits PS offer out weigh the loss in efficiency?

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

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

Редактировать: В ответ на первый комментарий:

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

Я бы предположил, что цель каждого в этом состоит в том, чтобы прийти к решению, которое они могут быть достаточно уверенно защищают от подвигов; и, конечно же, если вы используете религиозные подготовленные операторы или сознательно избегаете переменных запроса, когда это необходимо, то вы это сделали. ИМО должен подумать о том, насколько системен 1015 * мой подход к предотвращению эксплойтов SQL? Какой объем он предлагает для ошибок, чтобы не определить, когда вы создаете код, который будет иметь проблему?

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

Answer 3

Я не думаю, что это должно быть вопросом эффективности. Я сомневаюсь, что вы будете измерять значимую разницу, особенно по сравнению с задержкой в ​​сети для вызовов базы данных и неэффективностью, вносимой остальным кодом.

Преимущество защиты от SQL-инъекций само по себе стоит стоимости входа.

Я думаю, что это пример микрооптимизации, против которой предупреждал Дональд Кнут.

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