.net - sheet - Dapper y SQL Injections

sql injection test

Question

¿Cómo ayuda Dapper a proteger contra las inyecciones de SQL? Estoy probando diferentes tecnologías DAL y tengo que elegir una para asegurar nuestro sitio. Me estoy inclinando hacia Dapper (http://code.google.com/p/dapper-dot-net/), pero necesito ayuda para aprender sobre seguridad.

Answer 1

¿Cómo ayuda Dapper a proteger contra las inyecciones de SQL?

Hace realmente, realmente fácil hacer acceso a datos totalmente parametrizado, sin necesidad de concatenar ninguna entrada. En particular, debido a que no necesita saltar a través de "agregar parámetro, configure el tipo de parámetro, verifique nulo porque ADO.NET tiene sucky null-handling , enjuague / repita para 20 parámetros", al hacer el manejo de los parámetros estúpidamente conveniente . También hace que convertir filas en objetos sea realmente fácil, evitando la tentación de usar DataTable ... todos ganan.

De los comentarios:

Una más ... ¿qué hace Dapper realmente ayudar a hacer eso?

Para responder, tomemos el ejemplo de la respuesta de marc_s, y escribámoslo de la manera anterior, asumiendo que todo lo que tenemos que comenzar es la connection . Esto es entonces:

List<Dog> dogs = new List<Dog>();
using(var cmd = connection.CreateCommand()) {
    cmd.CommandText = "select Age = @Age, Id = @Id";
    cmd.Parameters.AddWithValue("Age", DBNull.Value);
    cmd.Parameters.AddWithValue("Id", guid);
    using(var reader = cmd.ExecuteReader()) {
        while(reader.Read()) {
            int age = reader.ReadInt32("Age");
            int id = reader.ReadInt32("Id");
            dogs.Add(new Dog { Age = age, Id = id });
        }
        while(reader.NextResult()) {}
    }
}

excepto que he simplificado demasiado, ya que también se ocupa de una amplia gama de problemas, tales como:

• nulo manejo de parámetros
• manejo nulo de columnas de resultados
• utilizando los índices de columnas ordinales
• adaptándose a los cambios estructurales de la tabla subyacente y tipo
• conversión de datos de columnas de resultados (entre varias primitivas, cadenas, enumeraciones, etc.)
• manejo especial de la situación tan común "en esta lista"
• para "ejecutar", manejo especial de "aplique esto por separado a una lista de entradas"
• evitando errores tipográficos
• reduciendo el mantenimiento del código
• manejo de múltiples grillas
• manejo de múltiples objetos devueltos horizontalmente en una sola cuadrícula
• trabajar con proveedores de ADO.NET arbitrarios (sugerencia: AddWithValue rara vez existe)
  • Incluye soporte específico para cosas como Oracle, que necesita configuración adicional
  • juega muy bien con decoratos de ADO.NET como "mini-profiler"
• compatibilidad incorporada para los accesos almacenados en búfer (adecuados para datos pequeños a moderados; minimiza la duración del comando) y no almacenados en búfer (adecuados para datos grandes; uso de memoria minimizado)
• optimizado por personas que se preocupan por el rendimiento y conocen "bastante" tanto el acceso a datos como la meta-programación
• le permite usar su opción de POCO / DTO / anon-type / whatever para el parámetro y la salida
• permite el uso de dynamic (para varias columnas) o primitivas, etc. (para una sola columna) cuando la salida no garantiza la generación de un POCO / DTO
• Evite los gastos generales de los ORM complejos y totalmente escritos, como EF
• evitar la sobrecarga de capas de tipo débil como DataTable
• abrir y cerrar conexiones según sea necesario
• y una amplia gama de otras trampas comunes

Answer 2

Solo necesita utilizar consultas parametrizadas como siempre debería. Dado que Dapper es solo una extensión "pequeña" (y bastante delgada) para SQL "en bruto" y ADO.NET, solo use consultas parametrizadas de ADO.NET y parámetros de suministro.

Vea este ejemplo del sitio Dapper-Dot-Net:

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", 
                                new { Age = (int?)null, Id = guid });

La consulta SQL usa parámetros, y los suministra a la consulta "Dapper".

Para resumir: el uso de Dapper en sí mismo no ayuda a proteger contra las inyecciones de SQL per se - utilizando consultas parametrizadas ADO.NET/SQL, sin embargo (y esas consultas son totalmente compatibles con Dapper, sin problemas)