Что такое серверный эквивалент Sql для Oracle DBMS_ASSERT?

Question

DBMS_ASSERT является одним из ключей, предотвращающих атаки SQL-инъекций в Oracle. Я пробовал краткий поиск ... есть ли какой-нибудь SQL Server 2005/2008 эквивалент для этой функции?

Я ищу конкретную реализацию, которая имеет аналог всех соответствующих членов пакета Oracle DBMS_ASSERT.

• NOOP
• SIMPLE_SQL_NAME
• QUALIFIED_SQL_NAME
• SCHEMA_NAME

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

У вас есть какие-то конкретные реализации?
Есть ли библиотека, которая на самом деле является портом SQL Server пакета Oracle?

Answer 1

Самое близкое, что у меня есть, это TSQLAssert для TSQLMacro , но он поддерживает только хранимые процедуры TSQL. Это бесплатно.

TSQLAssert - это структура утверждений построен на основе TSQLMacro. это предназначен для обеспечения времени отладки Сбои утверждения, аналогичные утверждения в таких языках, как C ++ - с дополнительным компонентом регистрации не найден в этих языках. TSQLAssert можно использовать только внутри хранимые процедуры и триггеры - к сожалению, пользовательские функции и мнения не поддерживают многие из ключевые слова, которые позволяют ему работать.

Answer 2

Не выполняйте динамические запросы, создавая строки и выполняя их.

Используйте sp_executesql и передайте параметры в качестве параметров.

Вы обнаружите, что SQL инъекций больше нет.

РЕДАКТИРОВАТЬ : извините, я спешил и написал неправильную команду. это не sp_execute, это sp_executesql; он принимает строку и набор параметров: все кодирование и экранирование параметров выполняется SQL Server.

EDIT2 : объяснение оператора sp_executesql

Answer 3

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

Не существует механизма для полной квалификации объекта (например, превращение таблицы 'bob' в 'database.owner.bob'), поэтому вам придется собрать это вместе вручную, необязательно используя QUOTENAME для выхода значения, например:

QUOTENAME(@database) + '.' + QUOTENAME(@owner) + '.' + QUOTENAME(@tableName)

Если объект находится в существующей базе данных, вы можете использовать DB_NAME () и предположить, что владелец будет передан как переменная:

DB_NAME() + '.' + QUOTENAME(@owner) + '.' + QUOTENAME(@tablename)

По-настоящему запутанным способом вы можете также вывести владельца:

USER_NAME(OBJECTPROPERTY(OBJECT_ID(@tablename), 'ownerid')))

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

Однако для экранирования значений вы действительно одиноки: встроенного эквивалента в SQL Server не существует, так что все ручные операции со строками будут выполняться. Возможно, вам удастся создать UDF, чтобы сделать это, хотя, если вы собираетесь это сделать, возможно, стоит также переписать sproc с использованием семантики SQL Server sp_ExecuteSQL.

Answer 4

Таким образом, в SQL SERVER нет эквивалента DBMS_ASSERT.

Однако, усиливая ответ Аарона Бертрана по этой ссылке SQL-инъекция

Answer 5

Нет волшебной команды «предотвратить впрыск». Методология представляет собой комбинацию:

1. Использование параметризованных запросов для обеспечения безопасности типов
2. Очистить входные данные перед их передачей на уровень базы данных
3. Если вы не можете выполнить 1. и 2., замените 'with' 'во всех входных данных и других методах очистки, прежде чем выполнять динамический SQL вслепую.

Answer 6

Я тоже однажды искал что-то похожее на DBMS_ASSERT для Sql Server, но безрезультатно. Так что я закончил тем, что написал набор необходимых нам PROC.

Microsoft действительно должна отправить что-то подобное, но до тех пор вы сами по себе.