Dapper и SQL-инъекции

Как Dapper помогает защититься от SQL-инъекций?

Это позволяет действительно, очень легко осуществлять полностью параметризованный доступ к данным без необходимости объединения входных данных. В частности, потому что вам не нужно перескакивать через множество «добавить параметр, установить тип параметра, проверить на нуль, потому что ADO.NET плохо обрабатывает нуль, промыть/повторить для 20 параметров» , сделав обработку параметров глупо удобной. Это также позволяет очень легко превращать строки в объекты, избегая соблазна использовать DataTable... выигрывают все.

Из комментариев:

Еще один... что же на самом деле помогает dapper?

Чтобы ответить, давайте возьмем пример из ответа marc_s и напишем его по-старому, предполагая, что все, с чего нам нужно начать, это connection. Это тогда:

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()) {}
    }
}

за исключением того, что я сильно упростил, поскольку он также касается широкого круга вопросов, таких как:

• нулевая обработка параметров
• нулевая обработка столбцов результатов
• используя порядковые индексы столбцов
• адаптация к структурным изменениям базовой таблицы и типа
• преобразование данных столбцов результатов (между различными примитивами, строками, перечислениями и т. д.)
• специальная обработка очень распространенного сценария «в этом списке»
• для «выполнить», специальная обработка «применить это отдельно к списку входов»
• избегать глупых опечаток
• сокращение обслуживания кода
• работа с несколькими сетками
• обработка нескольких объектов, возвращаемых горизонтально в одной сетке
• working with arbitrary ADO.NET providers (hint: AddWithValue rarely exists)
  • including specific support for things like Oracle, which needs additional configuration
  • прекрасно работает с декорациями ADO.NET, такими как "мини-профилировщик"
• встроенная поддержка как буферизованного (подходит для небольших и средних данных; минимизирует продолжительность команды), так и небуферизованного (подходит для больших данных; минимальное использование памяти) доступа
• оптимизирован людьми, которые заботятся о производительности и знают «довольно немного» как о доступе к данным, так и о метапрограммировании.
• позволяет вам использовать ваш выбор POCO/DTO/anon-type/что угодно как для параметра, так и для вывода
• позволяет использовать либо dynamic (для нескольких столбцов), либо примитивы и т. д. (для одного столбца), когда вывод не гарантирует создание POCO/DTO
• избежать накладных расходов сложных полнотипизированных ORM, таких как EF
• избегайте накладных расходов на слаботипизированные слои, такие как DataTable
• открытие и закрытие соединений по мере необходимости
• и широкий спектр других распространенных ошибок

Вам просто нужно использовать параметризованные запросы, как и всегда. Поскольку Dapper — это всего лишь «крошечное» (и довольно тонкое) расширение «сырого» SQL и ADO.NET — просто используйте параметризованные запросы ADO.NET и параметры поставки.

См. этот пример с сайта Dapper-Dot-Net:

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

В SQL-запросе используются параметры, и вы указываете их в запросе «Dapper».

Подводя итог: использование Dapper само по себе не помогает защититься от SQL-инъекций как таковое, однако использование параметризованных запросов ADO.NET/SQL помогает (и эти запросы полностью поддерживаются Dapper, никаких проблем вообще)