È ansible l’iniezione tramite Dynamic LINQ?

L’utilizzo della libreria Dynamic LINQ ( link ) è vulnerabile all’iniezione? e (in caso affermativo) come può essere protetto contro?

Alcune informazioni sulle considerazioni sulla sicurezza (Entity Framework) :

Attacchi di iniezione da LINQ a entity framework:

Sebbene la composizione della query sia ansible in LINQ alle quadro, viene eseguita tramite l’API del modello di oggetti. A differenza delle query SQL di Entity, le query LINQ to Entities non sono composte utilizzando la manipolazione o la concatenazione di stringhe e non sono suscettibili agli attacchi di SQL injection tradizionali.

Poiché Dynamic SQL è composto da stringhe vuol dire che potrebbe essere suscettibile ai vettori di iniezione? O LINQ to SQL si occuperà automaticamente della parametrizzazione dei valori in base al tipo di dati sottostante all’interno della libreria Dynamic LINQ?

O è completamente sicuro poiché la query dynamic verrà eseguita in memoria anziché contro SQL (annullando in tal modo eventuali vantaggi dagli indici SQL)?

Ho lavorato attraverso la comprensione del codice DynamicLibrary.cs ma sono sicuro che potrei facilmente trascurare qualcosa.

Poiché questa domanda riguarda direttamente la libreria Dynamic LINQ, questa domanda può essere considerata linq-to-sql sia per linq-to-sql che per linq-to-entities (nonostante il riferimento sopra a Entity Framework).

Bene, non sono d’accordo che l’iniezione non è ansible in Linq dynamic.

Quanto descritto nella risposta di Ɖiamond ǤeezeƦ è corretto, ma si applica alla Linq standard come costruita all’interno della lingua data – C # o VB.Net o chiamando metodi di estensione come .Where con funzioni lambda.

Quindi, è vero, non è ansible iniettare nulla poiché il traduttore .NET Linq to Sql è, ovviamente, scritto in modo decente. Pertanto, “l’iniezione SQL” non è ansible, è vero.

Tuttavia, ciò che è ansible con Dynamic Linq è l’attacco “Linq injection”. Nella spiegazione per la sicurezza di linq citata da OP, si afferma:

Le query LINQ to Entities non sono composte utilizzando la manipolazione o la concatenazione di stringhe e non sono suscettibili agli attacchi di SQL injection tradizionali.

E fondamentalmente questo è un succo. Se le query sono composte da una manipolazione di stringhe, è sobject a attacchi di iniezione. E Dynamic Linq è in realtà composto da stringhe, quindi è potenzialmente sobject ad attacchi per iniezione.

Ovviamente, l’utente malintenzionato dovrà essere consapevole del fatto che si sta utilizzando DynamicLinq e potrebbe attaccare solo la preparazione dei dati, in modo che si traduca in una query valida dynamic di Linq dynamic.

Voglio evidenziare questo fatto – l’ SQL finale è composto in modo sicuro , ma dipende dal fatto che la Linq dynamic originale sia sicura.

Il must per rendere sicura la tua query dynamic linq è usare segnaposti per tutti gli input dell’utente . Non concatenare mai la tua stringa!

Immagina la seguente query:

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

Se l’input non è disinfettato e non è sfuggito, l’autore dell’attacco potrebbe potenzialmente inserire:

 200" or allowed == 0 and code == "200 

quale risulterà in:

 allowed == 1 and code == "200" or allowed == 0 and code == "200" 

Per evitare questo, dovresti usare segnaposti:

 dataset.Where("allowed == 1 and code == @0", user_entered_data); 

DynamicLinq renderà il segnaposto (in questo caso: dati immessi dall’utente) un argomento lambda (anziché concatenarlo in una query) e dipenderà da Linq-To-Entities (o da qualsiasi back-end) per la conversione sicura in SQL.

Da quello che so esaminando lo spazio dei nomi System.Data.Linq è che una struttura ad albero SQL è costruita dalla query LINQ e come parte di questo processo viene chiamata la class SqlParameterizer per sostituire tutti i valori in linea con i parametri. I valori vengono quindi assegnati ai parametri. Quindi gli attacchi di SQL injection non dovrebbero essere possibili.