Question L'injection est-elle possible via LINQ dynamique?


Utilisation de la bibliothèque Dynamic LINQ (lien), est-il vulnérable à l'injection? et (si oui) comment cela peut-il être protégé?

Quelques antécédents de Considérations sur la sécurité (Entity Framework):

Attaques d’injection LINQ to Entities:

Bien que la composition des requêtes soit possible dans LINQ to Entities, elle est   effectué via l'API de modèle d'objet. Contrairement aux requêtes SQL d'entité,   Les requêtes LINQ to Entities ne sont pas composées en utilisant la manipulation de chaîne   ou concaténation, et ils ne sont pas sensibles à SQL traditionnel   attaques par injection.

Étant donné que le SQL dynamique est composé de chaînes, cela signifie-t-il qu'il peut être sensible aux vecteurs d'injection? Ou LINQ to SQL prendra-t-il automatiquement en charge le paramétrage de vos valeurs en fonction du type de données sous-jacent de la bibliothèque Dynamic LINQ?

Ou est-ce totalement sûr puisque la requête dynamique sera effectuée en mémoire plutôt que contre le SQL (annulant ainsi les avantages des index SQL)?

J'ai travaillé à comprendre le DynamicLibrary.cs code mais je suis sûr que je pourrais facilement être en train de négliger quelque chose.

Comme cette question concerne la bibliothèque Dynamic LINQ elle-même, cette question peut être considérée comme applicable à la fois linq-to-sql et linq-to-entities (malgré la référence ci-dessus à Entity Framework).


38
2018-01-05 07:20


origine


Réponses:


Eh bien, je ne suis pas d'accord que l'injection n'est pas possible dans Dynamic Linq.

Que décrit dans le répondre par Ondiamond ǤeezeƦ est correct mais correspond à la norme Linq construite dans la langue donnée - C # ou VB.Net ou en appelant des méthodes d'extension comme .Where avec des fonctions lambda.

Alors, vrai, il n'est pas possible d'injecter quoi que ce soit, car le traducteur .NET Linq to Sql est, bien sûr, écrit correctement. 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îne ou la concaténation, et elles ne sont pas sensibles aux attaques par injection SQL traditionnelles.

Et fondamentalement c'est une idée. Si les requêtes sont composées par manipulation de chaînes, elles sont sujettes à des attaques par injection. Et Dynamic Linq est en réalité composé de chaînes, donc il est potentiellement sujet à des attaques par injection.

De toute évidence, l'attaquant devra être conscient du fait que vous utilisez DynamicLinq et que vous ne pourrez attaquer que pour préparer les données, ce qui entraînera une requête Dynamic Linq malveillante valide.

Je veux souligner ce fait - la finale SQL est composé sans encombre, mais si original Linq dynamique est sécurisé dépend de toi.

Le must pour rendre votre requête linq dynamique est d'utiliser placeholders pour tous entrée utilisateur. Ne jamais concaténer votre chaîne!

Imaginez la requête suivante:

dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");

Si l'entrée n'est pas assainie et non é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: les données entrées par l’utilisateur) un argument lambda (au lieu de le concaténer en requête) et dépendra de Linq-To-Entities (ou de tout autre backend) pour se convertir en SQL en toute sécurité.


29
2018-01-26 17:13



De ce que je sais de l'examen de la System.Data.Linq namespace est qu'un arbre d'objet SQL est construit à partir de la requête LINQ et dans le cadre de ce processus le SqlParameterizer class est appelée pour remplacer toutes les valeurs en ligne par des paramètres. Les valeurs sont ensuite affectées aux paramètres. Les attaques par injection SQL ne devraient donc pas être possibles.


3
2018-01-05 10:25