Защитить API от SQL-инъекций

Question

Я создаю API. Приведенный ниже метод получает сотрудников по имени в параметре запроса или всех сотрудников. Однако защищает ли [FromQuery(Name = "name")] от внедрения SQL, не уверенный, является ли это функцией по умолчанию .NET core 2.2?

[HttpGet]
public IActionResult GetStaff([FromQuery(Name = "name")] string firstName)
{
    if (firstName == null)
    {
       //get all staff
       var staff = _repo.GetAllStaff().ToList();
       return Ok(staff);
    }

    if (firstName != null)
    {
       //get staff by firstName
       var staffByName = _repo.GetStaffByName(firstName).ToList();
       return Ok(staffByName);
    }

    return BadRequest("No staff found");
}

Метод в репозитории

    public IEnumerable<ApiStaff> GetStaffByName(string name)
    {
        var staffName = _context.ApiStaff.Where(k => k.FirstName == name);
        return staffName;
    }

Answer 1

Из вашего вопроса неясно, используете ли вы ORM, например, инфраструктуру сущностей, однако, судя по соглашениям об именах _context и запросу Where linq, я думаю, что вы.

Ядро ASP.net не имеет встроенного средства предотвращения внедрения SQL как такового. Фактически Ядро Asp.net больше не имеет встроенной проверки правильности запроса .

Однако при использовании ORM имеет некоторые естественные средства предотвращения внедрения SQL :

LINQ to Entities Атаки:

Хотя составление запроса возможно в LINQ to Entities, оно выполняется через API объектной модели. В отличие от запросов Entity SQL, Запросы LINQ to Entities не составляются с использованием строковых операций или объединение, и они не восприимчивы к традиционному SQL инъекционные атаки.

Это не тот случай, если вы выбрали выполнение SQL напрямую в ORM, поэтому это зависит от того, как вы его используете.

Безопасность следует рассматривать как «глубокую защиту», добавляя методы смягчения на каждом уровне или границе вашего приложения.

Простым примером для вашего варианта использования может быть ограничение имени разумными значениями, например, длиной не более X символов (30?), Без цифр и т. Д., Однако это легче сказать, чем сделать для интернационализация следовательно, даже если в Entity Framework обнаружена слабость, вы мешаете атакующему, предоставляя ему только ограниченный набор символов для атаки.

Я бы рекомендовал прочитать шпаргалку OWASP