d'échappement en apostrophes Linq base procédure stockée appelle lorsque SP contient SQL dynamique

Question

j'ai remarqué ce qui suit:

Un site Web ASP.NET MVC en cours de développement obtient une erreur SQL « guillemet Unclosed ... » quand il fait un LINQ appel à une procédure stockée contenant du SQL dynamique.

Par exemple:

SP GetEmployees appelé avec le paramètre [filter_name] qui a une valeur [N'for] jette cette erreur

je peux résoudre le problème en faisant une .replace ("'", " '' ") 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 de passer par tous mes SP et de le faire manuellement. Y a-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 dans le futur?

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

EDIT:

question Ajouté: Est-ce donner des problèmes avec les PC qui ne comprennent DonT sql dynamique? Je veux dire, quand j'ajoute ce nom dans la base de données, sera-t-il stocké comme [n''for]? Je viens de me rendre compte que ce sera probablement le cas et je devrais le faire manuellement de toute façon

Answer 1

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

Il semble plus correct que cela devrait être géré à l'intérieur du SP. L'application ne devrait pas avoir à se soucier de savoir si un certain SP contient 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 que cela pourrait causer beaucoup d'autres problèmes, et pourrait ne pas être possible.)

Sauf si vous pouvez garantir que le SQL dynamique que vous construisez est sûr, (donc vous contrôlez cette logique en interne, sans rien passé par l'utilisateur), ça va être un problème. Que se passerait-il si filter_name contenait un \ 'or -?