c# - query - ¿Es posible la inyección a través de LINQ dinámico?

linq to entities join

Question

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

Algunos antecedentes de Consideraciones de seguridad (Entity Framework) :

LINQ para ataques de inyección de Entidades:

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

Dado que el SQL dinámico está compuesto por cadenas, ¿significa que podría ser susceptible a los vectores de inyección? ¿O LINQ to SQL se encargará automáticamente de parametrizar sus valores en función del 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 contra el SQL (negando así cualquier beneficio de los índices de SQL)?

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

Como esta pregunta es sobre la propia biblioteca de LINQ dinámica, se puede considerar que esta pregunta se aplica tanto a linq-to-sql como a linq-to-entities (a pesar de la referencia anterior al Entity Framework).

Answer 1

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

Lo que se describe en la answer de ondiamond ǤeezeƦ es correcto, pero se aplica a Linq estándar tal como está construido dentro del lenguaje dado - C # o VB.Net o llamando a métodos de extensión como .Where con funciones lambda.

Entonces, es cierto, no es posible inyectar nada, ya que, por supuesto, el traductor .NET Linq to Sql está escrito decentemente. 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 de Linq". En la explicación para la seguridad de linq citado por OP, se establece:

Las consultas de LINQ to Entities no se componen mediante el uso de la manipulación de cadenas o la concatenación, y no son susceptibles a los ataques de inyección de 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 cadenas, por lo que es potencialmente propenso a los ataques por inyección.

Obviamente, el atacante tendrá que ser consciente del hecho de que está utilizando DynamicLinq y podría atacar solo preparando los datos para que resulte en una consulta de Linq dinámico maliciosa válida.

Quiero resaltar este hecho: el SQL final está compuesto de manera segura , pero si Linq dinámico original es seguro depende de usted .

El requisito para que su consulta dinámica de linq sea segura es utilizar marcadores de posición para todas las entradas del usuario . ¡Nunca concatene su cadena!

Imagina la siguiente consulta:

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

Si la entrada no está saneada y no se escapa, el atacante podría ingresar:

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

lo que resultará en:

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

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

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

DynamicLinq convertirá el marcador de posición (en este caso: datos ingresados ​​por el usuario) en un argumento lambda (en lugar de concatenarlos en una consulta) y dependerá de Linq-To-Entities (o cualquier otra parte) para convertir de forma segura a SQL.

Answer 2

Por lo que sé por examinar el espacio de nombres System.Data.Linq es que se construye un árbol de objetos SQL 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.