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

Если динамический SQL встроен в код с использованием следующего экранирования перед отправкой на SQL Server, какой тип внедрения может победить это?

string userInput= "N'" + userInput.Replace("'", "''") + "'"

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

Экранирование одинарной кавычки с "\" невозможно в SQL Server.

я верюSQL-контрабанда с Юникодом (обрисовано в общих чертахВот) будет сорван тем фактом, что создаваемая строка помечается как Unicode буквой N, предшествующей одинарной кавычке. Насколько я знаю, нет других наборов символов, которые SQL Server автоматически переводил бы в одну кавычку. Без единой кавычки без экранирования я не верю, что инъекция возможна.

Я не верюУсечение строки является жизнеспособным вектором либо. SQL Server, конечно, не будет выполнять усечение, так как максимальный размер дляnvarchar 2 ГБв соответствии с Microsoft, Строка размером 2 ГБ невозможна в большинстве ситуаций и невозможна в моей.

Инъекция второго порядка возможно, но возможно ли это:

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

Я не утверждаю, что это лучше или альтернативно использованию параметризованных запросов, но я хочу знать, насколько уязвимо то, что я изложил. Есть идеи?