Para começar, estou ciente de que as consultas parametrizadas são a melhor opção, mas estou perguntando o que torna a estratégia que apresento abaixo vulnerável. As pessoas insistem que a solução abaixo não funciona, então estou procurando um exemplo do porquê disso não acontecer.

Se o SQL dinâmico é construído em código usando o seguinte escape antes de ser enviado para um SQL Server, que tipo de injeção pode derrotar isso?

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

Uma pergunta semelhante foi respondidaAqui, mas não acredito que nenhuma das respostas seja aplicável aqui.

Escapar da aspa simples com um "\" não é possível no SQL Server.

AcreditoContrabando de SQL com Unicode (delineadoAqui) seria frustrado pelo fato de que a cadeia que está sendo produzida é marcada como Unicode pelo N anterior à aspa simples. Tanto quanto sei, não há outros conjuntos de caracteres que o SQL Server iria automaticamente traduzir para uma aspa simples. Sem uma única citação sem escape, não acredito que a injeção seja possível.

Eu não acreditoTruncamento de Cadeia é um vetor viável também. O SQL Server certamente não fará o truncamento desde o tamanho máximo de umnvarchar é 2GBde acordo com a microsoft. Uma string de 2 GB é inviável na maioria das situações e impossível na minha.

Injeção de segunda ordem poderia ser possível, mas é possível se:

Todos os dados que entram no banco de dados são higienizados usando o método acimaOs valores do banco de dados nunca são acrescentados ao SQL dinâmico (por que você faria isso de qualquer forma, quando você pode apenas referenciar o valor da tabela na parte estática de qualquer string SQL dinâmica?).

Não estou sugerindo que isso seja melhor ou uma alternativa ao uso de consultas parametrizadas, mas quero saber como o que delineei é vulnerável. Alguma ideia?