V5608. OWASP. Possible SQL injection. Potentially tainted data is used to create SQL command.

Анализатор обнаружил создание SQL-команды из данных, полученных из внешнего источника, без предварительной проверки. Это может стать причиной возникновения SQL-инъекции в случае, если данные будут скомпрометированы.

SQL инъекции выделены в отдельную категорию рисков в OWASP Top 10 Application Security Risks 2017: A1:2017-Injection.

Рассмотрим пример:

void ProcessUserInfo()
{
  using (SqlConnection connection = new SqlConnection(_connectionString))
  {
    ....
    String userName = Request.Form["userName"];

    using (var command = new SqlCommand()
    {
      Connection = connection,
      CommandText = "SELECT * FROM Users WHERE UserName = '" + userName + "'",
      CommandType = System.Data.CommandType.Text
    })
    {            
      using (var reader = command.ExecuteReader())
        ....
    }
  } 
}

В данном случае при формировании SQL-команды используется значение переменной 'userName', полученной из внешнего источника — 'Request.Form'. Использование данных без какой-либо проверки является опасным, так как открывает злоумышленникам разные способы внедрения команд.

Например, вместо ожидаемого значения имени пользователя злоумышленник может ввести специальную команду. Тогда из базы произойдёт извлечение данных всех пользователей, для которых будет запущена дальнейшая обработка.

Пример такой скомпрометированной строки:

' OR '1'='1

Для защиты от подобных запросов следует проводить валидацию входных данных или, например, использовать параметризованные команды.

Пример кода с использованием параметризированных команд:

void ProcessUserInfo()
{
  using (SqlConnection connection = new SqlConnection(_connectionString))
  {
    ....
    String userName = Request.Form["userName"];
    
    using (var command = new SqlCommand()
    {
      Connection = connection,
      CommandText = "SELECT * FROM Users WHERE UserName = @userName",
      CommandType = System.Data.CommandType.Text
    })
    {
      var userNameParam = new SqlParameter("@userName", userName);
      command.Parameters.Add(userNameParam);
            
      using (var reader = command.ExecuteReader())
        ....
    }
  } 
}

Анализатор также считает небезопасными источниками параметры методов, доступных из других сборок. Пользователи таких сборок могут рассчитывать на то, что валидация данных будет происходить внутри вызываемого метода. Однако, так как ни пользователь библиотеки, ни её разработчик не провели валидацию входных данных, это может стать причиной возникновения уязвимостей при использовании скомпрометированных данных.

Рассмотрим пример:

public class DBHelper
{
  public void ProcessUserInfo(String userName)
  {
    ....
    var command = "SELECT * FROM Users WHERE userName = '" + userName + "'";
    ExecuteCommand(command);
    ....
  }

  private void ExecuteCommand(String rawCommand)
  {
    using (SqlConnection connection = new SqlConnection(_connectionString))
    {
      ....
      using (var sqlCommand = new SqlCommand(rawCommand, connection))
      {
        using (var reader = sqlCommand.ExecuteReader())
          ....
      }
    }
  }
}

Класс 'DBHelper' предоставляет метод 'ProcessUserInfo' для внешнего использования, так как он доступен из других сборок. Однако параметр этого метода - 'userName' - никак не проверяется перед использованием. Значение, полученное извне, напрямую используется для формирования команды (переменная 'command'). Далее полученная команда передаётся в метод 'ExecuteCommand', где без проверки используется для создания объекта типа 'SQLCommand'.

В данном случае анализатор выдаст предупреждение на вызов метода 'ExecuteCommand', принимающего в качестве аргумента заражённую строку.

Теперь рассмотрим возможный вариант использования метода 'ProcessUserInfo':

static void TestHelper(DBHelper helper)
{
  var userName = Request.Form["userName"];
  helper.ProcessUserInfo(userName);
}

Разработчик, написавший подобный код, может не иметь доступа к коду класса 'DBHelper' и рассчитывать на то, что валидация входных данных будет происходить внутри метода 'ProcessUserInfo'. Так как ни текущий код, ни код метода 'ProcessUserInfo' не провёл валидацию данных, этот код будет уязвимым для SQL инъекций.

Хотя подобные случаи могут привести к возникновению уязвимости, явного внешнего источника данных при анализе кода 'DBHelper' нет. Поэтому анализатор выдаст предупреждение с низким уровнем достоверности, если источником входных данных считаются параметры методов, доступных внешним сборкам.

Данная диагностика классифицируется как: