Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
Taint-анализ (taint checking)

Taint-анализ (taint checking)

17 Авг 2021

Taint-анализ (или taint checking) – это технология, позволяющая отслеживать распространение непроверенных внешних данных по программе во время её работы. Попадание таких данных в некоторые ключевые точки может приводить к возникновению различных уязвимостей, среди которых SQL injection, cross-site scripting (XSS), path traversal и другие. Эти уязвимости могут быть использованы злоумышленником для нарушения корректной работы системы, получения конфиденциальных данных или проведения прочих несанкционированных операций.

Источники заражения

Первичным понятием в данной теме являются заражённые данные. Под этим термином подразумеваются некоторые значения, которые могут позволить злоумышленнику выполнить несанкционированные и, как правило, вредоносные операции при взаимодействии с системой. В зависимости от способа использования внешних данных приложение может быть уязвимо к тем или иным атакам. Например, если приложение использует непроверенные внешние данные при формировании запросов к БД, то оно может быть уязвимо к SQL injection.

Таким образом, внешние данные являются потенциально заражёнными. Точки, в которых приложение получает к ним доступ, называют источниками заражения (taint source). Например, источником заражения может быть операция получения значения параметра HTTP-запроса:

void ProcessRequest(HttpRequest request)
{
  ....
  string name = request.Form["name"]; // taint source
  // now "name" contains potentially tainted data
  ....
}

Передача заражения

Важным аспектом при проведении taint-анализа является определение "трасс распространения" заражённых данных по приложению. В приведённом примере заражённые данные из источника передаются в переменную name. Впоследствии они могут также переходить в другие переменные или выступать в качестве аргументов функций:

void ProcessRequest(HttpRequest request)
{
  string name = request.Form["name"]; // taint source
  // now "name" contains potentially tainted data

  string sql = $"SELECT * FROM Users WHERE name='{name}'";
  ExecuteReaderCommand(sql); // tainted data passed as an argument
  ....
}

void ExecuteReaderCommand(string sql)
{
  // sql contains potentially tainted data here 
  ....
}

Стоит отметить, что заражение может передаваться далеко не только при присваивании и передаче аргументов. В примере выше переменная name, хранящая потенциально заражённые данные, используется для формирования строки, которая будет записана в переменную sql. В результате значение sql также будет потенциально заражённым.

Приёмники заражения

С точки зрения taint-анализа, приложение уязвимо в случае, если заражённые данные могут попасть в некоторые ключевые точки приложения. Их называют приёмниками заражения (taint sink). Каждой потенциальной уязвимости соответствуют свои приёмники. Для SQL injection, к примеру, приёмником может являться точка передачи строки запроса в объект SQL команды:

void ProcessRequest(HttpRequest request)
{
  string name = request.Form["name"]; // <= taint source
  // now "name" contains potentially tainted data

  string sql = $"SELECT * FROM Users WHERE name='{name}'";
  ExecuteReaderCommand(sql); // tainted data passed as an argument
  ....
}

void ExecuteReaderCommand(string sql)
{
  using (var command = new SqlCommand(sql, _connection)) // <= sink
  {
    using (var reader = command.ExecuteReader()) { /*....*/ }
  }
  ....
}

Здесь внешние данные из источника (request.Form["name"]) непосредственно используются при формировании sql-запроса, который далее передаётся в приёмник — конструктор SqlCommand. Задача taint-анализа состоит в проверке наличия пути передачи заражённых данных от источника к приёмнику.

По сути, taint-анализ является одной из форм статического анализа. Таким образом, он вполне может быть реализован в соответствующих инструментах в качестве отдельного механизма или набора диагностических правил. К примеру, если проверить вышеприведённый код с помощью PVS-Studio, то результатом станет следующее предупреждение: "V5608 Possible SQL injection inside method. Potentially tainted data in the first argument 'sql' is used to create SQL command".

Для полноты картины приведём другой пример атаки – XSS (межсайтовый скриптинг). Она позволяет злоумышленнику внедрять вредоносный код на открываемые пользователями веб-страницы. Приёмником в данном случае может являться вызов метода Response.Write:

protected void Page_Load(object sender, EventArgs e)
{
  ....

  var userName = Request.Params["userName"];  // taint source
  
  string message;
  if (string.IsNullOrWhiteSpace(userName))
  {
    message = "Empty 'userName' parameter";
  }
  else
  {
    message = $"'{userName}' data has been processed.";
  }
  
  Response.Write(message);          // taint sink
}

Производя taint-анализ, PVS-Studio обнаружил здесь возможность попадания данных из Request.Params["userName"] в Response.Write и сформировал соответствующее предупреждение:

V5610 Possible XSS vulnerability. Potentially tainted data in the 'message' variable might be used to execute a malicious script.

В данном случае уязвимость состоит в следующем: если в параметр запроса userName будет записан вредоносный скрипт, то из-за вызова Response.Write он попадёт на загружаемую пользователем страницу и впоследствии выполнится.

Подробнее о различных типах уязвимостей можно прочитать в документации к соответствующим диагностическим правилам:

Устранение потенциальных уязвимостей

Для устранения потенциальной уязвимости внешние данные необходимо проверять или преобразовывать в некоторый безопасный вид. Конкретный способ защиты зависит от типа атаки. Например, в случае с SQL injection могут быть использованы параметризованные запросы:

String userName = Request.Form["userName"];
String query = "SELECT * FROM Users WHERE UserName = @userName";

using (var command = new SqlCommand(query, _connection))
{
  var userNameParam = new SqlParameter("@userName", userName);
  command.Parameters.Add(userNameParam);
            
  using (var reader = command.ExecuteReader())
  ....
}

Соответственно, при проведении taint-анализа предупреждение на данный код выдано не будет.

Для других атак также предусмотрены свои способы защиты. Например, в случае с XSS можно использовать специальные методы преобразования внешних данных. Одним из них является HtmlEncode:

protected void Page_Load(object sender, EventArgs e)
{
  String userName = Request.Form["userName"];
  ....
  var encodedUserName = System.Net.WebUtility.HtmlEncode(userName);
  var message = $"'{encodedUserName}' data has been processed.";
  
  Response.Write(message);
}

Благодаря такой обработке вредоносный скрипт попадёт на страницу в виде обычного текста. Следовательно, никакие опасные действия выполняться не будут.

Дополнительные ссылки

Популярные статьи по теме
Комментарии в коде как вид искусства

Дата: 04 Май 2022

Автор: Сергей Хренов

Приветствую всех программистов, а также сочувствующих. Кто из нас хотя бы раз в жизни не оставлял комментарии в коде? Был ли это ваш код, а может, чужой? Что за комментарии вы написали: полезные или …
Visual Studio 2022 стильно и свежо. История о её поддержке в PVS-Studio

Дата: 15 Фев 2022

Автор: Николай Миронов

Кажется, анонс Visual Studio 2022 был только недавно, и вот она уже вышла. Это означало ровно одно – поддержать данную IDE нужно в ближайшем релизе PVS-Studio. О том, с какими сложностями пришлось ст…
Лучшие срабатывания статического анализатора

Дата: 29 Окт 2021

Автор: Максим Звягинцев

У всех, кто запускал статический анализатор в первый раз на большом проекте, был небольшой шок по поводу сотен, тысяч или даже десятков тысяч предупреждений. Как-то грустно становится после такого. Т…
Зачем нужна техническая поддержка и как в ней не выгореть?

Дата: 01 Сен 2021

Автор: Николай Миронов

Не всем нравится работать в поддержке. Огромное количество людей выгорает на ней. Так может не стоит вообще её иметь? Какую выгоду она несёт? Можно ли как-то не выгорать от поддержки? Попробуем найти…
Как делался новый дизайн сайта PVS-Studio

Дата: 04 Июн 2021

Автор: Инна Пристягина

Сайту PVS-Studio в этом году исполнится 15 лет. Это солидный возраст для любого интернет-ресурса. Далёкий 2006-й в России был признан годом гуманитарных наук. В июне появилась никому не знакомая тогд…

Комментарии (0)

Следующие комментарии
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять