Предотвращение внедрения SQL - почему следует избегать ввода, если использовать подготовленные операторы? - PullRequest
Новая
       16

Предотвращение внедрения SQL - почему следует избегать ввода, если использовать подготовленные операторы?

6 голосов
/ 03 января 2012

Я провожу некоторые исследования в области веб-безопасности, и ревизор моей статьи сказал:

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

Мой вопрос: одного из этих методов недостаточно?Хорошо, подготовленные операторы или хранимые процедуры лучше простого экранирования, но если я использую PDO, почему мне следует избегать ввода или иметь хранимую процедуру?Имеет ли это смысл?

Ответы [ 3 ]

8 голосов
/ 03 января 2012

Я бы изменил формулировку редакции на:

Должно быть ясно, что во избежание SQL-инъекции приложение должно использовать подготовленные операторы, экранировать ввод или фильтровать данные приложения перед интерполяцией в строку SQL.

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

Вам нужно интерполировать строки в оператор SQL, когда вы не можете использовать параметр запроса. Примеры включают в себя:

  • Имена таблиц и столбцов, которые имеют собственный синтаксис для идентификаторов с разделителями . Они должны быть частью запроса SQL во время подготовки, чтобы СУБД могла их анализировать и проверять.

  • Ключевые слова SQL, которые должны быть очищены, но не могут быть экранированы, потому что они не разделены.

  • Другой синтаксис или выражения.

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

Хранимые процедуры не являются защитой от внедрения SQL. Вы можете подготовить и выполнить небезопасные динамические операторы SQL внутри хранимой процедуры. См. http://thedailywtf.com/Articles/For-the-Ease-of-Maintenance.aspx, чтобы узнать больше об этом.

Я рассматриваю все эти случаи в своей презентации Мифы и ошибки SQL-инъекций . Это может быть полезным ресурсом для вас.

Я также расскажу о защите от внедрения SQL в главе моей книги, Антипаттерны SQL: предотвращение ловушек программирования баз данных .

4 голосов
/ 03 января 2012

Если я использую PDO, почему я должен [es] обрезать ввод или иметь хранимую процедуру?

Пока вы всегда используете PDO, яне вижу причин беспокоиться о экранировании ввода или SP.

2 голосов
/ 03 января 2012

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

Вы не должны сбегать, если используете PDO.Вы не должны уходить, если используете подготовленные операторы JDBC с параметрами .Точно так же большинство других API также заботятся об этом.Хранимые процедуры даже не связаны с экранированными данными, и их использование не может волшебным образом избежать проблем безопасности внедрения SQL, если входные данные не экранируются в SQL, который выполняет процедуру.

Всегда данные SQL-Escape, которые вы вводите вПредложения SQL.Никогда не используйте SQL-Escape вне предложений SQL.

...