Para empezar, soy consciente de que las consultas parametrizadas son la mejor opción, pero me pregunto qué hace que la estrategia que presento a continuación sea vulnerable. La gente insiste en que la siguiente solución no funciona, así que busco un ejemplo de por qué no lo haría.

Si el código SQL dinámico está integrado en el siguiente escape antes de enviarlo a un servidor SQL, ¿qué tipo de inyección puede vencer esto?

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

Una pregunta similar fue respondidaaquí, pero no creo que ninguna de las respuestas sean aplicables aquí.

Escapar de la comilla simple con un "\" no es posible en SQL Server.

Yo creoContrabando de SQL con Unicodeaquí) se vería frustrado por el hecho de que la cadena que se está produciendo está marcada como Unicode por la N que precede a la comilla simple. Que yo sepa, no hay otros conjuntos de caracteres que SQL Server se traduciría automáticamente en una sola cita. Sin una sola cita sin escaparse, no creo que la inyección sea posible.

No creoTruncamiento de cuerdas Es un vector viable tampoco. SQL Server ciertamente no hará el truncamiento ya que el tamaño máximo para unnvarchar es 2GBsegun microsoft. Una cadena de 2 GB es inviable en la mayoría de las situaciones, e imposible en la mía.

Inyección de segundo orden podría ser posible, pero es posible si:

Todos los datos que entran en la base de datos se sanean utilizando el método anteriorLos valores de la base de datos nunca se agregan a SQL dinámico (¿por qué haría eso de todos modos, cuando solo puede hacer referencia al valor de la tabla en la parte estática de cualquier cadena de SQL dinámico?).

No estoy sugiriendo que esto sea mejor o una alternativa al uso de consultas parametrizadas, pero quiero saber cómo lo que describí es vulnerable. ¿Algunas ideas?