Могу ли я избежать всех SQL-инъекций, используя параметры?

Question

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

Answer 1

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

Например, это подвержено атаке внедрения SQL: ваш параметризованный запрос передает имя пользователя хранимой процедуре,и в хранимой процедуре параметр объединяется с командой SQL и затем выполняется.

Пример многих видов атак с использованием SQL-инъекций см. в этом Шпаргалке по SQL-инъекциям .Вы увидите, что простое экранирование одинарных кавычек просто царапает поверхность, и что есть много способов обойти это.

Answer 2

Да и нет.Да, если все ваши операторы SQL действительно являются статическими и используют только параметры, тогда вы на 100% защищены от атак с использованием SQL-инъекций.

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

Answer 3

Да, вы можете избежать всех атак SQL-инъекций, используя параметры, если вы используете параметры исключительно на всем протяжении стека вызовов . Например:

• Код вашего приложения вызывает хранимую процедуру или динамический SQL в базе данных. Это должно использовать параметры для передачи всех значений.
• Хранимая процедура или динамический SQL внутренне создает вызов другой хранимой процедуры или динамического оператора SQL. Это также должно использовать параметры для передачи всех значений.
• Повторяйте до бесконечности, пока не закончится код.

Если вы программируете на SQL Server, вы можете использовать sp_executesql для выполнения динамического SQL, и это позволит вам определять и передавать параметризованные значения в выполняемый оператор.

Answer 4

Если вы собираетесь построить динамический SQL-запрос с этими параметрами (например, переданный в хранимую процедуру), тогда есть вероятность внедрения SQL-кода, если не будут приняты меры предосторожности.

Answer 5

Проблема заключается в динамическом построении оператора SQL.

Например, вы можете упорядочить результат по столбцу, выбранному пользователем. В большинстве баз данных вы не можете использовать параметры здесь («ORDER BY?» Не работает). Таким образом, вы должны "ORDER BY" + столбец. Теперь, если «column» является String, тогда пользователь вашего веб-приложения может ввести туда код (что не просто, но возможно).

Answer 6

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

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