escapar de apóstrofes en llamadas a procedimientos almacenados basados ??en Linq cuando SP contiene SQL dinámico

Question

Noté lo siguiente:

Un sitio web ASP.NET MVC en desarrollo obtiene un error de SQL " Comillas no cerradas ... " cuando realiza una llamada LINQ a un procedimiento almacenado que contiene SQL dinámico.

Por ejemplo:

SP GetEmployees llamado con el parámetro [nombre_filtro] que tiene el valor [n'for] arroja este error

Puedo solucionar el problema haciendo un .replace (" '" ;, "' '") así:

[Function(Name = "dbo.GetEmployees")]
public ISingleResult<EmployeeRow> GetEmployees(
            [Parameter(DbType = "NVarChar(MAX)")] string filter_name)
{
    IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), filter_name.Replace("'", "''"));
    return ((ISingleResult<EmployeeRow>)(result.ReturnValue));
}

Ahora, no tengo ganas de revisar todos mis SP y hacer esto manualmente. ¿Hay alguna manera de hacer de esto una regla general que deba aplicarse a todas las llamadas de Linq SP que tengo ahora y que haré en el futuro?

Además, ¿hay algo más de lo que deba escapar para evitar ataques de inyección SQL?

EDITAR:

Pregunta agregada: ¿Esto dará problemas con los SP que no incluyen sql dinámico? Quiero decir, cuando agregue ese nombre en la base de datos, ¿se almacenará como [n''para]? Me acabo de dar cuenta de que probablemente este sea el caso y luego tendré que hacerlo manualmente de todos modos

Answer 1

Voy a dar una (posible) respuesta aquí a mi propia pregunta. (hágamelo saber en los comentarios si está de acuerdo)

Parece más correcto que esto se maneje dentro del SP. La aplicación no debería tener que preocuparse por si cierto SP contiene sql dinámico o no.

Answer 2

Le sugiero que se aleje del SQL dinámico, ya que esa es la raíz del problema. (Sé que esto podría causar muchos otros problemas, y podría no ser posible).

A menos que pueda garantizar que el SQL dinámico que está creando es seguro (por lo que controla esta lógica internamente, sin que el usuario pase nada), será un problema.

¿Qué pasaría si filter_name contuviera un \ 'o -?