¿Es esta declaración LINQ vulnerable a la inyección de SQL?

Question

¿Es esta declaración LINQ vulnerable a la inyección de SQL?

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

donde context es una Entidad y pruebas es una tabla. Estoy tratando de aprender LINQ y pensé que el beneficio de esto era que no era vulnerable a la inyección sql, pero algunas cosas que he visto han dicho de manera diferente. ¿Tendría que parametrizar esta declaración LINQ para que sea más seguro? ¿Si es así, cómo?

¿Esto también se consideraría linq a sql o linq a las entidades?

Answer 1

Respuesta corta: LINQ no es vulnerable a la inyección de SQL.

Respuesta larga:

LINQ no es como SQL. Hay una biblioteca detrás de escena que construye SQL a partir de árboles de expresiones generados por el compilador a partir de su código, asignando los resultados a los objetos y, por supuesto, se ocupa de hacer las cosas seguras en el camino.

Ver LINQ to SQL FAQ:

P. ¿Cómo se LINQ a SQL protegida ataques de inyección SQL?

A. La inyección de SQL ha sido un riesgo significativo para las consultas SQL tradicionales formadas por la entrada concatenada del usuario . LINQ to SQL evita dicha inyección mediante el uso de SqlParameter en consultas . La entrada del usuario se convierte en valores de parámetro . Este enfoque impide que los comandos maliciosos sean utilizados a partir de la entrada del cliente.

Internamente, significa que cuando LINQ a SQL consulta la base, en lugar de utilizar los valores de fricción, que los pasa como parámetros SQL, que significa que pueden Nunca ser tratados como código ejecutable por la base de datos.Esto también es cierto para la mayoría (si no para todos) de los mapeadores ORM que existen.

comparar estos dos enfoques (totalmente pseudo-código):

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 

le sugiero que profundizar más en lo que realmente significan las declaraciones de LINQ y cuándo y cómo se traduce a SQL real. Es posible que desee obtener información acerca de LINQ standard query operator translation, deferred execution, different LINQ providers y demás. En el caso de LINQ, al igual que cualquier tecnología de abstracción, es a la vez fascinante e increíblemente útil saber lo que está sucediendo detrás de escena.

P.S. Cada vez que veo una pregunta sobre la inyección de SQL, no puedo evitar recordar este webcomic.

Answer 2

No. LINQ to Entities y LINQ to SQL manejan la generación de consultas SQL para evitar la inyección SQL. Puede usar LINQPad si tiene curiosidad por ver qué declaración SQL se genera cuando ejecuta esta consulta con varias entradas.

Si se trata de LINQ to SQL o LINQ to Entities depende de lo que sea el objeto context, y no se puede determinar a partir de este fragmento de código.

La única vez que debe preocuparse por la inyección SQL en LINQ es si está utilizando el método ExecuteQuery para ejecutar una consulta SQL personalizada (see here). Pero en ese momento, te alejaste de Language-Integrated Query y volviste al mundo de la generación de tus propias cadenas.

Answer 3

LINQ utiliza consultas parametrizadas por lo que generalmente no es susceptible a la inyección SQL. Tu ejemplo, por ejemplo, no es vulnerable.

Answer 4

El proveedor de LINQ to Entities utiliza consultas parametrizadas y es completamente seguro contra la inyección SQL.

Answer 5

LINQ To SQL genera una consulta parametrizada por lo que protege contra ataques de inyección SQL

Answer 6

LINQ paramaterizes todas las consultas, por lo que no es susceptible a ataques de inyección SQL. Sin embargo, aún debe validar toda su información de usuario, ya que de lo contrario se dejará abierto a ataques de scripts cruzados.