Questa classificazione LINQ è vulnerabile all'iniezione SQL?

Question

Questa classificazione LINQ è vulnerabile all'iniezione SQL?

var result = from b in context.tests 
    where b.id == inputTextBox.Text 
    select b; 

cui contesto è un'entità e test è una tabella. Sto cercando di imparare LINQ e ho pensato che il vantaggio derivasse dal fatto che non era vulnerabile a SQL injection, ma alcune cose che ho visto hanno detto in modo diverso. Dovrei parametrizzare questa istruzione LINQ per renderla più sicura? Se é cosi, come?

Anche questo sarebbe considerato da linq a sql o linq alle entità?

Answer 1

Risposta breve: LINQ non è vulnerabile a SQL injection.

Risposta lunga:

LINQ non è come SQL. C'è un'intera libreria dietro le quinte che costruisce SQL dagli alberi di espressione generati dal compilatore dal tuo codice, mappando i risultati agli oggetti, e ovviamente si occupa di rendere le cose sicure lungo la strada.

Vedi LINQ to SQL FAQ:

D. Come è LINQ to SQL protetto dallo attacchi SQL-injection?

A. L'SQL injection ha rappresentato un rischio significativo per le query SQL tradizionali formate da concatenazione dell'input dell'utente . LINQ to SQL evita tale iniezione utilizzando SqlParameter nelle query . L'input dell'utente viene convertito nei valori dei parametri . Questo approccio impedisce l'utilizzo di comandi dannosi dall'input del cliente.

Internamente, significa che quando LINQ to SQL interroga il database, invece di utilizzare i valori semplici, che passa come parametri SQL, che significa che possono mai essere trattati come codice eseguibile dal database.Questo vale anche per la maggior parte (se non tutti) i mappatori ORM là fuori.

confrontare questi due approcci (totalmente pseudo-codice):

string name = "' ; DROP DATABASE master --" 
run ("SELECT * FROM Authors WHERE Name = '" + name + "'") // oops! 

// now we'd better use parameters 
SqlParameter name = new SqlParameter ("@name", "' ; DROP DATABASE master --") 
run ("SELECT * FROM Authors WHERE Name = @name", name) // this is pretty safe 

vi consiglio di immergersi in quello che le dichiarazioni LINQ realtà significa e quando e come essi vengono tradotti al reale SQL. Si consiglia di conoscere LINQ standard query operator translation, deferred execution, different LINQ providers e così via. In caso di LINQ, proprio come qualsiasi altra tecnologia di astrazione, è allo stesso tempo affascinante e incredibilmente utile sapere cosa succede dietro le quinte.

P.S. Ogni volta che vedo una domanda su SQL injection non posso fare a meno di ricordare questo webcomic.

Answer 2

No. LINQ to Entities e LINQ to SQL gestiscono la generazione di query SQL per evitare SQL Injection. È possibile utilizzare LINQPad se si è curiosi di vedere quale istruzione SQL viene generata quando si esegue questa query con vari input.

Sia che si tratti di LINQ to SQL o LINQ per entità, dipende da cosa è l'oggetto e non può essere determinato da questo snippet di codice.

L'unica volta che devi preoccuparti dell'iniezione SQL in LINQ è se stai utilizzando il metodo ExecuteQuery per eseguire una query SQL personalizzata (see here). Ma a quel punto, ti sei allontanato dalla Query integrata dalla lingua e sei tornato nel mondo della generazione delle tue stringhe.

Answer 3

LINQ utilizza query parametrizzate, pertanto non è generalmente suscettibile all'iniezione SQL. Il tuo esempio, per esempio, non è vulnerabile.

Answer 4

Il provider LINQ to Entities utilizza query parametrizzate ed è completamente sicuro contro l'iniezione SQL.

Answer 5

LINQ to SQL genera una query parametrizzata in modo che protegge contro gli attacchi SQL injection

Answer 6

Linq paramaterizes tutte le query, quindi non è suscettibile di attacchi di SQL injection. Tuttavia, dovresti comunque convalidare tutti gli input dell'utente, altrimenti ti lascerai aperto agli attacchi cross-site scripting.