¿Es posible la inyección a través de Dynamic LINQ?

Question

Usando la biblioteca Dynamic LINQ (link), ¿es vulnerable a la inyección? y (de ser así) ¿cómo puede protegerse esto?

Algunos antecedentes de Security Considerations (Entity Framework):

LINQ a Entidades ataques de inyección:

Aunque composición consulta es posible en LINQ a Entidades, se realiza a través de la API de modelo de objetos. A diferencia de las consultas de Entity SQL, Las consultas de LINQ to Entities no se componen mediante la manipulación de cadenas ni la concatenación, y no son susceptibles a los ataques de inyección SQL tradicionales.

Dado que el SQL dinámico se compone de cadenas, ¿eso significa que podría ser susceptible a los vectores de inyección? ¿O LINQ to SQL automáticamente se encargará de parametrizar sus valores basados ​​en el tipo de datos subyacente dentro de la biblioteca Dynamic LINQ?

¿O es completamente seguro ya que la consulta dinámica se realizará en la memoria en lugar de hacerlo en el SQL (anulando así los beneficios de los índices SQL)?

He estado trabajando entendiendo el código DynamicLibrary.cs, pero estoy seguro de que podría pasar fácilmente por alto algo.

Como esta pregunta es acerca de la Biblioteca LINQ dinámica en sí misma, se puede considerar que esta pregunta se aplica tanto a linq-to-sql como a linq-to-entities (a pesar de la referencia anterior a Entity Framework).

Answer 1

Bueno, no estoy de acuerdo con que la inyección no sea posible en Dynamic Linq.

Lo que se describe en la answer por Ɖiamond ǤeezeƦ es correcta, pero a appies estándar de LINQ como construidos dentro de la lengua dada - C# o VB.Net o llamando a los métodos de extensión como .Where con funciones lambda.

Entonces, cierto, no es posible inyectar nada ya que el traductor .NET Linq a Sql es, por supuesto, decentemente escrito. Por lo tanto, la "inyección SQL" no es posible, eso es cierto.

Sin embargo, lo que es posible con Dynamic Linq es el ataque de "inyección Linq". En la explicación de seguridad de LINQ citadas por OP, se afirma:

LINQ a Entidades consultas no están compuesta por el uso de la manipulación de cadenas o concatenación, y no son susceptibles a ataques de inyección SQL tradicionales.

Y, básicamente, esto es una esencia. Si las consultas están compuestas por manipulación de cadenas, entonces es propenso a ataques de inyección. Y Dynamic Linq en realidad está compuesto de cuerdas, por lo tanto, es potencialmente propenso al ataque por inyección.

Obviamente, el atacante tendrá que ser consciente del hecho de que está utilizando DynamicLinq y podría atacar solo la preparación de los datos, por lo que da como resultado una consulta maliciosa de Dynamic Linq válida.

quiero destacar este hecho - la final SQL se compone segura, pero ya sean originales dinámica LINQ es seguro depende de usted.

El mosto para hacer su consulta LINQ dinámica segura es el uso de marcadores de posición para todas las entradas de usuario . ¡Nunca concatenas tu cadena!

Imagínese la siguiente consulta:

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

Si la entrada no es verificada y no se escapó, el atacante podría potencialmente entrada:

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

que se traducirá en:

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

Para evitar esto, debe usar marcadores de posición:

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

DynamicLinq hará que el marcador de posición (en este caso: los datos introducidos por el usuario) un argumento lambda (en lugar de la concatenación en la consulta) y dependen de LINQ a las entidades (o cualquier sistema backend es) para convertir de manera segura a SQL.

Answer 2

De lo que sé al examinar el espacio de nombres System.Data.Linq es que un árbol de objetos SQL se construye a partir de la consulta LINQ y como parte de este proceso se llama a la clase SqlParameterizer para reemplazar todos los valores en línea con parámetros. Los valores se asignan a los parámetros. Por lo tanto, los ataques de inyección SQL no deberían ser posibles.