apostrofi di escape nelle chiamate di procedure memorizzate basate su Linq quando SP contiene SQL dinamico

Question

Ho notato quanto segue:

Un sito Web ASP.NET MVC in fase di sviluppo riceve un errore SQL "virgolette non chiuse ..." quando effettua una chiamata LINQ a una stored procedure che contiene SQL dinamico.

Ad esempio:

SP GetEmployees chiamato con il parametro [filter_name] che ha valore [n'for] genera questo errore

Posso risolvere il problema facendo un .replace (" '" ;, "' '") come questo:

[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));
}

Ora, non mi va di sfogliare tutti i miei SP e farlo manualmente. C'è un modo per rendere questa una regola generale che dovrebbe essere applicata a tutte le chiamate Linq SP che ho adesso e che farò in futuro?

Inoltre, c'è qualcos'altro che dovrei scappare per prevenire attacchi di iniezione SQL?

EDIT:

Domanda aggiunta: questo causerà problemi con SP che non includono sql dinamico? Voglio dire, quando aggiungo quel nome nel database, sarà memorizzato come [n''per]? Ho appena realizzato che probabilmente sarà così e poi dovrò farlo manualmente comunque

Answer 1

Darò una (possibile) risposta qui alla mia domanda. (fatemi sapere nei commenti se siete d'accordo)

Sembra più corretto che questo debba essere gestito all'interno di SP. L'applicazione non dovrebbe preoccuparsi del fatto che un determinato SP contenga sql dinamico o meno.

Answer 2

Ti suggerisco di allontanarti dall'SQL dinamico, poiché questa è la radice del problema. (So ??che questo potrebbe causare molti altri problemi e potrebbe non essere possibile.)

A meno che non sia possibile garantire che l'SQL dinamico che si sta creando sia sicuro, (quindi si controlla questa logica internamente, senza che nulla venga passato dall'utente), sarà un problema.

Cosa succederebbe se filter_name contenesse un \ 'o -?