L'Injection est-elle Possible via Dynamic LINQ?
En utilisant la bibliothèque Linq dynamique (link ), est-elle vulnérable à l'injection? et (si oui) comment cela peut-il être protégé contre?
Contexte de considérations de sécurité (Entity Framework):
LINQ aux attaques D'injection D'entités:
Bien que la composition de requête soit possible dans LINQ to Entities, elle est effectué via L'API du modèle objet. Contrairement aux requêtes SQL Entity, Les requêtes LINQ to Entities ne sont pas composées à l'aide de string manipulation ou concaténation, et ils ne sont pas sensibles au SQL traditionnel attaques par injection.
Puisque le SQL dynamique est composé en utilisant des chaînes, cela signifie-t-il qu'il pourrait être sensible aux vecteurs d'injection? Ou LINQ to SQL s'occupera-t-il automatiquement de paramétrer vos valeurs en fonction du type de données sous-jacent dans la bibliothèque Linq dynamique?
Ou est-ce entièrement sûr puisque la requête dynamique sera effectuée en mémoire plutôt que contre le SQL (ainsi annuler tous les avantages des index SQL)?
J'ai travaillé à comprendre le code DynamicLibrary.cs mais je suis sûr que je pourrais facilement ignorer quelque chose.
Comme cette question concerne la bibliothèque Linq dynamique elle-même, cette question peut être considérée comme s'appliquant à la fois à linq-to-sql et linq-to-entities (malgré la référence ci-dessus à Entity Framework).
2 réponses
Eh bien, je ne suis pas d'accord que L'injection N'est pas possible dans Dynamic Linq.
Ce qui est décrit dans la réponse par iiamond Ǥeeze { est correct mais s'applique à Linq standard tel qu'il est construit dans la langue donnée-C# ou VB.Net ou en appelant des méthodes d'extension comme .Where avec des fonctions lambda.
Alors, c'est vrai, il n'est pas possible d'injecter quoi que ce soit car le.net Linq To Sql translator est, bien sûr, écrit décemment. Ainsi, l '"injection SQL" n'est pas possible, c'est vrai.
Cependant, ce qui est possible avec Dynamic Linq est l'attaque "LINQ injection". Dans L'explication de la sécurité de linq Citée par OP, il est indiqué:
Les requêtes LINQ to Entities ne sont pas composées en utilisant la manipulation de chaînes ou la concaténation, et elles ne sont pas sensibles aux attaques par injection SQL traditionnelles.
Et fondamentalement, c'est un essentiel. Si les requêtes sont composées par manipulation de chaîne, elles sont sujettes aux attaques par injection. Et dynamique Linq est en fait composé de chaînes, il est donc potentiellement sujet à l'attaque par injection.
Évidemment, l'attaquant devra être conscient du fait que vous utilisez DynamicLinq et pourrait attaquer seulement préparer les données de sorte qu'il en résulte une requête LINQ dynamique malveillante valide.
, je tiens à souligner ce fait - la finale SQL est composé en toute sécurité, mais si original dynamique Linq est sûr dépend de vous.
Le must à faire votre coffre-fort de requête LINQ dynamique consiste à utiliser espaces réservés pour toutes les entrées utilisateur. Ne concaténez jamais votre chaîne!
Imaginez la requête suivante:
dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");
Si l'entrée n'est pas aseptisée et n'est pas échappée, l'attaquant pourrait potentiellement entrer:
200" or allowed == 0 and code == "200
Ce qui entraînera:
allowed == 1 and code == "200" or allowed == 0 and code == "200"
Pour éviter cela, vous devez utiliser des espaces réservés:
dataset.Where("allowed == 1 and code == @0", user_entered_data);
DynamicLinq fera de L'espace réservé (dans ce cas: données saisies par l'utilisateur) un argument lambda (au lieu de concaténer en requête) et dépendent de Linq-to-Entities (ou quel que soit le backend) pour convertir en toute sécurité en SQL.
D'après ce que je sais de l'examen de l'espace de noms System.Data.Linq, une arborescence D'objets SQL est construite à partir de la requête LINQ et, dans le cadre de ce processus, la classe SqlParameterizer est appelée pour remplacer toutes les valeurs en ligne par des paramètres. Les valeurs sont ensuite affectées aux paramètres. Donc, les attaques par injection SQL ne devraient pas être possibles.