2011-05-11 13 views
5

Actualmente estoy haciendo un proyecto con C# y LINQ-TO-SQL. Este proyecto tiene la seguridad como una prioridad alta, así que obviamente quiero evitar las inyecciones de SQL. Busqué en Google sobre el tema, pero no está resultando nada útil. propia FAQ de Microsoft me dijo que las inyecciones habría ningún problema, debido a la forma de LINQ maneja parámetros, sin embargo viendo el LINQ código produce en un depurador y después de haber leído un poco sobre cómo LINQ a SQL simplemente construye a SQL No estoy Seguro cómo esto aplica.¿Cómo evita LINQ-To-SQL Inyecciones SQL?

¿Alguien tiene alguna literatura/vinculación que se ocupe de este asunto?

Respuesta

6

LINQ to SQL utiliza automáticamente SQLParameters. La entrada del usuario se convierte en valores de parámetros en lugar de simplemente ser una cadena concatenada (que es lo que permite las inyecciones de SQL). Esto ocurre en el lado del servidor, IIRC, por lo que es posible que solo esté viendo el código del lado del cliente. Si desea un poco más de antecedentes e información, puede leer the information here.

+0

Vale, la página 2 del artículo debitado de mi pregunta. ¡Gracias por su respuesta! – fk2

6

Es bastante simple, realmente - la traducción nunca inyecta variables sin parametrizarlas; por lo que:

var orders = from ord in ctx.Orders 
      where ord.CustomerName = name 
      select ord; 

se convertirá en:

SELECT * FROM [dbo].[Orders] WHERE [CustomerName] = @p0 

donde p0 es un parámetro con el valor tomado de su capturado name

nada más y nada menos. Pero esto evita los ataques de inyección. Contraste con un incorrecta accidental:

var sql = "SELECT * FROM [dbo].[Orders] WHERE [CustomerName] = '" + name + "'"; 

que introduce riesgos enormes. Por supuesto, puede parametrizar el anterior correctamente, también:

var sql = "SELECT * FROM [dbo].[Orders] WHERE [CustomerName] = @name"; 

(y añadir un parámetro con el valor de @namename)

+0

¿Cómo así? Digamos que tengo un campo de entrada que contiene una Cadena. Alguien ingresa "; Drop Database" o algo similar. Esto evalúa 'SELECT * FROM [Orders] WHERE [CustomerId] =; Drop Database'. ¿No tengo un problema, entonces? – fk2

+0

@ FK2, no creo que entienda SQL parametrizada ... – canon

+1

@ FK2 '@ p0' *** *** es un parámetro; nunca se evalúa como TSQL; puede ser cualquier contenido de cadena, sin ningún riesgo –

Cuestiones relacionadas