échapper aux apostrophes lors d'appels de procédures stockées basés sur Linq lorsque SP contient du SQL dynamique

Question

J'ai remarqué ce qui suit:

Un site Web ASP.NET MVC en cours de développement génère une erreur SQL "Guillemet non fermé ...". lorsqu’il appelle LINQ vers une procédure stockée contenant du SQL dynamique.

Par exemple:

SP GetEmployees appelé avec le paramètre [nom_filtre] ayant la valeur [n'for] lève cette erreur

Je peux résoudre le problème en effectuant un .remplace ("" "", "" ") comme ceci:

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

Maintenant, je n'ai pas envie d'aller dans tous mes SP et de le faire manuellement. Existe-t-il un moyen d’en faire une règle générale qui devrait être appliquée à tous les appels Linq SP que j’ai maintenant et que je ferai à l’avenir?

De plus, y a-t-il autre chose que je devrais échapper pour empêcher les attaques par injection SQL?

EDIT:

Question ajoutée: Cela posera-t-il des problèmes avec les SP qui n'incluent pas SQL dynamique? Je veux dire, quand j'ajouterai ce nom dans la base de données, sera-t-il stocké sous la forme [n''for]? Je viens de me rendre compte que ce sera probablement le cas et ensuite je devrai le faire manuellement de toute façon

Answer 1

Je vais donner ici une réponse (possible) à ma propre question. (laissez-moi savoir dans les commentaires si vous êtes d'accord)

Il semble plus correct que cela soit géré dans le SP. L’application ne devrait pas avoir à s’inquiéter de savoir si un certain SP contient du SQL dynamique ou non.

Answer 2

Je vous suggère de vous éloigner du SQL dynamique, car c’est la racine du problème. (Je sais cependant que cela pourrait causer beaucoup d'autres problèmes et pourrait ne pas être possible.)

Si vous ne pouvez pas garantir la sécurité du SQL dynamique que vous créez (pour que vous puissiez contrôler cette logique en interne, rien ne passe par l'utilisateur), cela posera problème.

Que se passerait-il si filter_name contenait un \ 'ou -?