Помогает ли хранимая процедура устранять SQL-инъекцию/Каковы преимущества хранимых процедур в нормальных выражениях SQL в приложениях?

Ответ 1

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

Однако при использовании исключительно хранимые процедуры позволяют добавить дополнительную защиту, позволяя вам отключать разрешения для всех, кроме команды EXEC. Помимо этого, параметризованные запросы/подготовленные операторы обычно кэшируются сервером, и так же, как и хранимая процедура, почти во всех отношениях.

Несмотря на это, хранимые процедуры имеют два больших преимущества для крупных предприятий:

• Они позволяют вам определить интерфейс приложения для базы данных, чтобы система могла использоваться совместно несколькими приложениями без необходимости дублирования логики в этих приложениях.
• Они перемещают код sql в db, где вы можете легко настраивать, обновлять и иным образом поддерживать его, а не разработчики приложений, которые часто не знают точно, что они делают с кодом базы данных.

Конечно, эти преимущества не без стоимости:

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

Ответ 2

Некоторые из преимуществ, которые я считаю при использовании хранимых процедур

• Хранимые процедуры инкапсулируют код запроса на сервере, а не внутри вашего приложения. Это позволяет вам вносить изменения в запросы без необходимости перекомпилировать ваше приложение.
• Сохраненные процедуры могут использоваться для более четкой защиты приложений. Вы можете отменить все права на базовые таблицы, предоставить выполнение только на proc. Это дает вам гораздо меньший размер безопасности для управления.
• Сохраненные процедуры - это скомпилированный код. С последними версиями MSSQL сервер делает лучшую работу по хранению планов выполнения - так что это не такая большая проблема, как раньше, но все же что-то для рассмотрения
• Хранимые процедуры исключают риск инъекции SQL ТОЛЬКО при правильном использовании. Обязательно используйте параметры в правильном пути внутри хранимых обработанных procs, которые просто выполняют конкатенированный динамический SQL внутри них, не делают ничего хорошего.

Ответ 3

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

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

Я рекомендую слой DAL реализовать один из двух способов.

• Мой любимый, используйте объект реляционная система управления (ORM). Я работал с nHibernate и мне это очень нравится. кривая обучения в крутом, но определенно стоит выигрыш в моем мнение.
• Какой-то механизм поддержания весь ваш код SQL в одном месте. Либо какая-то библиотека запросов вы выбираете или действительно структурированный набор классов, которые спроектируйте SQL для вас. Я не рекомендую этот путь, так как это в основном, как создание собственной ORM и вероятность того, что у вас нет времени чтобы сделать это правильно.

Забудьте хранимые процедуры. Используйте ORM.

Ответ 4

Хранимые процедуры позволяют хранить код sql в месте вне приложения. это дает вам возможность:

• Измените код SQL без перекомпиляции/перераспределения приложения
• Попросите несколько приложений использовать одну и ту же хранимую процедуру для доступа к тем же данным.
• Ограничить доступ пользователей к чтению/записи в таблицы непосредственно в базе данных.
• С точки зрения развития он также позволяет программистам баз данных/баз данных работать с кодом sql без необходимости использования кода приложения для его работы. (разделение обязанностей по существу).

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

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

Я согласен с другими людьми, хранимые процедуры могут быть громоздкими, но у них также есть свои преимущества. Там, где я работаю, у нас есть, вероятно, 20 различных производственных баз данных по различным причинам (не спрашивайте). Я работаю над подмножеством, возможно, трех, и мой товарищ по команде, и я знаю, что эти трое действительно очень хорошо. Как хранимые процедуры помогают нам? Люди приходят к нам, и когда им нужно получить эту информацию из этих баз данных, мы можем получить ее за них. Нам не нужно часами объяснять схемы и какие данные де-нормировать. Это слой абстракции, который позволяет нам программировать наиболее эффективный код по отношению к базам данных, которые мы знаем. Если это не относится к вам, то, возможно, хранимые процедуры не подходят, но в некоторых случаях они могут добавить большую ценность.

Ответ 5

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

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