Как я создал систему безопасности для плагинов: от идеи до реализации

Примечание: в статье будут приводиться примеры псевдокода.

В этой статье я расскажу, как реализовал систему безопасности для своего пет-проекта - менеджера плагинов. Расскажу, какие задачи пришлось решать, и как получилось встроить защиту без потери гибкости и архитектурной чистоты.

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

Стоит подметить, что я начинающий разработчик, поэтому я не претендую на идеальность принятых мною решений.

Вступление

Контекст

Система безопасности создавалась для моего менеджера плагинов - инструмента, который позволяет динамически загружать плагины из .dll сборок, реализующие специальное API.

Плагины бывают разные: от выполнения простого скрипта до работы с файловой системой или отправки HTTP-запросов. Каждый плагин может иметь JSON-конфигурацию, в которой он может указывать необходимые ему зависимости (имя зависимости + минимальная версия).

В основе менеджера лежит система метаданных, которая создаётся при регистрации каждой сборки.

Она содержит:

• Информацию о найденных в ней плагинах

• Данные для быстрого поиска нужной сборки.

Метаданные активно используются другими частями системы - логгерами, трекерами и, теперь, системой безопасности.

Причина создания сервиса безопасности

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

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

Главные задачи системы безопасности

На первый взгляд задача кажется простой - достаточно проанализировать сборку с помощью библиотеки Mono.Cecil и отловить "нежелательные" конструкции.

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

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

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

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

Реализацию системы безопасности я проводил пошагово - от малого к большему.

Начало реализации

Интеграция в менеджер

Интегрировать новую систему безопасности получилось довольно просто - с помощью реализации паттерна "Наблюдатель". Этот паттерн в моем случае идеально подошел, так как все необходимые интерфейсы в проекте уже реализованы. Таким образом хранилище метаданных сборок стало субъектом наблюдения, а система безопасности - его наблюдателем. Как только в хранилище появляются новые метаданные - система безопасности реагирует на это и получает метаданные добавленной в хранилище сборки.

public class AssemblyMetadataRepository : IObservableMetadataRepository 
{
  private readonly List<IMetadataRepositoryObserver> _observers = new();

  public void AddMetadata(AssemblyMetadata metadata)
  {
    // Сообщаем наблюдателям о появлении новых метаданных
    foreach (var observer in _observers)
      observer.OnMetadataAdded(metadata);
  }
}

public class AssemblySecurityService : IMetadataRepositoryObserver
{
  // Реагируем на появление новых метаданных
  public void OnMetadataAdded(AssemblyMetadata metadata)
  {
    CheckSafety(metadata)
  }

  private bool CheckSafety(AssemblyMetadata metadata)
  {
    // Проверка базопасности
    ...
  }
}

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

Первый шаг - статическая обработка сборок

Первым делом я добавил статический анализ сборки с помощью ранее упомянутой библиотеки Mono.Cecil

Изначально я анализировал только подозрительные пространства имен, по типу System.IO, System.Net, System.Reflection, System.Reflection.Emit, и пространства имен вручную добавленные пользователем. Спустя некоторое время я также добавил анализ на реализацию контрактов безопасных сервисов, для того чтобы избежать уязвимостей создания подделок.

public class AssemblySecurityService 
{
  private readonly HashSet<string> _blockedNamespaces = new();


  // Можно добавить запрещенное пространство имен
  public void AddBlockedNamespace(string blockedNamespace)
  {
    // Валидация
    ...
    _blockedNamespaces.Add(blockedNamespace)
  }

  // Анализируем используемые в сборке пространства имен
  public bool AnalyzeNamespaces(string pathToAssembly)
  {
    // Извлекаем сборку для статического анализа
    var assembly = AssemblyDefinition.ReadAssembly(pathToAssembly);
    ...
    // Проверяем пространства имен сборки на подозрительные
    if (_blockedNamespaces.Any(banned => namespacesFromAssembly.StartsWith(banned)))
       return false;

    return true;
  }

  // Проверяем какие интерфейсы реализуют типы в сборке
  public bool AnalyzeInterfaces(string pathToAssembly)
  {
    // Извлекаем сборку для статического анализа
    var assembly = AssemblyDefinition.ReadAssembly(pathToAssembly);
    ...
    // Проверяем, не реализует ли тип из сборки запрещенный интерфейс
    if (typeFromAssembly.InterfaceType == typeof(ISafetyService))
      return false;

    return true;
  }
}

Второй шаг - внедрение безопасных сервисов

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

На уровне API будет реализован контракт безопасного сервиса, который позволит взаимодействовать только с разрешенными путями. Реализация этих сервисов будет находиться в отдельной сборке, которую я назвал инфраструктурной - она будет недоступной для плагинов.

Это даёт нам несколько преимуществ:

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

• Статический анализ кода не будет засекать запрещенное пространство имён System.IO, поскольку оно используется в другой сборке - инфраструктурной.

Для большей безопасности созданные безопасные сервисы не будут владеть методами добавления разрешений, создадим для этого отдельный компонент - контроллер разрешений, который также будет отвечать за валидацию/нормализацию путей. При создании экземпляра сервиса будем передавать контроллер с разрешениями - сервис извлечет из него все разрешения.

// Сборка PluginAPI
// Контракт безопасного сервиса. Будет использоваться плагинами.
public interface ISafetyService
{
  void DoSafetyAction();
}

// Сборка PluginInfrastructure - невидима для PluginAPI
// Реализация безопасного сервиса (передаем контроллер с разрешениями)
public class SafetyService(SafetyPermissionController controller) : ISafetyService
{
  public void DoSafetyAction()
  {
    // Реализация сервиса
    ...
  }
}

// Контроллер в который добавляем разрешенные пути
public class SafetyPermissionController
{
  public void AddPermission(string permission)
  {
    // Валидация, нормализация, добавление разрешения
    ...
  }
  public IEnumerable<string> GetAllPermissions()
  {
    // Получаем все разрешения
    ...
  }
}

Реализация безопасных сервисов

После того как я подготовил проект к изменениям - создал необходимые интерфейсы, продумал логику, я приступил к реализации безопасных сервисов.

1. Базовая реализация

Изначально реализация была очень простой - сервис просто хранил разрешенные пути. При обращении к сервису он проверял, разрешен ли запрашиваемый путь.

2. Политики доступа

Чуть позже я реализовал политику доступа к ресурсам: теперь для каждого пути можно указать, можно ли по нему читать или записывать данные.

3. Дополнительные ограничения

Чтобы повысить безопасность и стабильность я добавил:

• Ограничение размера файла, с которым сервисы могут работать. Пользователь может настроить это ограничение.

• Буферизация данных - для оптимизации памяти и защиты от "файловых бомб", если плагин неожиданно начнет читать или записывать огромные файлы.

4. Конфигурирование через API

Все настройки доступны через API менеджера плагинов - пользователь сам может задать допустимые пути, политики и ограничения. Это делает сервисы гибкими и более удобными в использовании.

public class Permission
{
  public string Path { get; set; }
  
  // Можно ли прочитать данные по пути
  public bool CanReadFromPath { get; set; }

  // Можно ли записать данные по пути
  public bool CanWriteToPath { get; set; }
}

public class SafetyService
{
  // Храним разрешения
  private readonly Dictionary<string, Permission> _permissions;

  // Ограничение на размер обрабатываемых данных
  private readonly long _maxFileSize;

  // Получаем настройки извне (настройки пользователя)
  public SafetyService(ISafetyServiceController controller, SafetyServiceSettings settings)
  {
    _permissions = controller.GetPermissions();
    _maxFileSize = settings.MaxFileSizeBytes;
  }

  // Проверяем: есть ли разрешение + разрешена ли операция
  private bool IsPathAllowed(string path, bool isRead)
  {
    // Проверяем разрешение, политику доступа
  }

  public void DoAction(string path)
  {
    IsPathAllowed(path, true);

    // Проверяем размер данных, используем буферизацию для работы с ними
  }
}

Как плагин будет получать необходимые разрешения?

Как я указывал выше - плагин может иметь JSON-конфигурацию. Теперь в этой конфигурации плагин сможет указывать к каким внешним ресурсам ему необходим доступ - например доступ к определенной папке/файлу, или URL.

Важное примечание:

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

Пример конфигурации плагина:

{
  "Permissions": {
    "FileSystem": [
      "D:\\SomePath",
      "D:\\SecondPath"
    ],
    "Network": [
      "http://somesite.com"
    ]
  }
}

Проверка безопасности конфигурации плагина

Для этого добавим новый компонент - PermissionSecurityService.

Он:

• Хранит разрешенные пользователем пути и политики доступа к ним (например путь D:\SomePath - только для чтения)

• При регистрации сборки анализирует конфигурации ее плагинов.

• Если плагин запрашивает доступ к ресурсу, который не разрешен в компоненте - сборка не проходит проверку.

public class PermissionSecurityService
{
  private readonly Dictionary<string, Permission> _permissions = new();

  // Добавить разрешение, указать политику доступа
  public void AddPermission(string path, bool canRead, bool canWrite)
  {
    // Валидация, нормализация
    ...

    // Создаем и добавляем разрешение
    _permissions.Add(path, new Permission(path, canRead, canWrite))
  }

  // Вызывается при регистрации сборки в менеджере
  public void OnMetadataAdded(AssemblyMetadata metadata)
  {
    // Получаем метаданные плагинов, которые содержат конфигурацию
    var plugins = metadata.Plugins;
    
    // Сверяем конфигурацию каждого плагина с разрешениями компонента
    ...
  }
}

Поскольку в системе безопасности теперь работают два компонента - статическая проверка и анализ конфигурации - я объединил их в единый фасад SecurityService.

Я понимаю что такая проверка получилась очень строгой. Но это был осознанный выбор - только пользователь решает, какие ресурсы доступны плагину.

Чтобы сгладить такую строгость я добавил:

• Импорт настроек безопасности из JSON-конфигурации. Это нужно для того чтобы не пришлось добавлять множество настроек вручную через код.

• Рекурсивное добавление разрешений (опционально). Это удобно если нужно открыть доступ ко всей структуре папок, а не перечислять все вручную. Например если пользователь добавит рекурсивный доступ к D:\SomePath, плагин сможет также взаимодействовать с D:\SomePath/FirstPath/SecondPath.

Внедрение сервисов в плагин

Честно говоря, это одна из частей системы в которой я все еще вижу потенциал для улучшения.

Сначала я хотел реализовать внедрение по такому шаблону:

• API плагинов ничего не знает о внедрении сервисов (то-есть не видит методов для внедрения).

• О внедрении сервисов знает только менеджер - это можно было бы реализовать через методы расширения.

Однако я столкнулся с такой проблемой:

• Для того чтобы расширяющий метод мог внедрить сервис - он должен иметь доступ к полю сервиса, то-есть поле плагина должно быть публичным.

• Но если у плагина будет публичное поле - нет смысла в расширяющем методе, API все-равно сможет устанавливать значение в это поле.

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

Вот как это примерно выглядит:

// Базовый класс для работы с файловой системой, который реализовывается плагинами.
public abstract class FilePluginBase : IFilePlugin
{
  // Флаг который указывает, был ли внедрен сервис
  private bool _isServiceInjected = false;

  // Свойство которое содержит безопасный сервис. Изначально содержит заглушку
  // без реализации.
  protected ISafetyService FileSystemService { get; private set; } = new FileSystemServiceStub();

  // Метод который отвечает за внедрение безопасного сервиса. После первого внедрения
  // устанавливает флаг в true, из-за чего больше внедрить сервис не получится.
  public void InjectService(ISafetyService service)
  {
    if (_isServiceInjected)
      return;

    FileSystemService = service;
    _isServiceInjected = true;
  }
    
  public abstract Task WriteFileAsync(byte[] data);
  public abstract Task<byte[]> ReadFileAsync();
}

В целом, я думаю текущая реализация вполне покрывает потребности моего менеджера, но если у вас есть идеи на этот счет - с радостью приму их к сведению!

Уязвимости и их устранение

Теперь пора рассказать о уязвимостях которые были обнаружены в моей системе безопасности, и о том, как я их устранил.

1. Создание подделок безопасного сервиса

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

Детали уязвимости

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

Пример подделки:

// Сборка с поддельным сервисом - FakeService.dll
public class FakeService : ISafetyService
{
  public void DoAction(string path)
  {
    // На сервис могут не действовать никакие ограничения, что позволяет получить
    // доступ к любому файлу
    File.Delete(path);
  }
}

// Сборка с плагинами - ссылается на FakeService.dll
public class Plugin : IPlugin
{
  // Выполняется при запуске плагина
  public void Execute()
  {
    // Создаем поддельный сервис, который не будет зафиксирован системой безопасности. 
    // Теперь мы можем получить доступ к любому файлу
    var fakeService = new FakeService();
    fakeService.DoAction("D:\очень_ценный_файл.txt");
  }
}

Оценка опасности

Исходя из деталей уязвимости мы понимаем - для того чтобы плагин смог получить доступ к поддельному сервису - загрузчик должен разрешить зависимости этой сборки.

Зависимость может разрешиться если:

• Cборка с подделкой лежит в той же папке, что и сборка с плагинами.

• В папке с плагинами лежит файл deps.json, который хранит путь к необходимой зависимости.

Cтоит учитывать, что эта уязвимость сработает только если пользователь отдельно зарегистрирует опасную сборку по ее имени. Если пользователь зарегистрирует все сборки из каталога разом - сборка с поддельными сервисами попадет в область видимости менеджера и не пройдет проверку безопасности.

Я бы оценил опасность этой уязвимости на 3/5 - позволяет без ограничений взаимодействовать с файловой системой, но требует определенных условий, которые никак не зависят от плагина.

Устранение

Устранить эту уязвимость получилось довольно просто - в системе безопасности будем использовать AssemblyDependencyResolver для разрешения зависимостей загружаемых сборок - которые также будут проходить проверку.

public class AssemblySecurityService : IAssemblySecurityService
{
  // Используется для защиты от бесконечной рекурсии
  private readonly HashSet<string> _checkedAssemblies = new();
  
  public bool CheckSafety(string assemblyPath)
  {
    // Если сборка уже была обработана - значит сборка безопасная
    if(_checkedAssemblies.Add(assemblyPath))
      return true;
    
    // Считываем сборку
    var assembly = AssemblyDefinition.ReadAssembly(assemblyPath);

    // Регистрируем разрешитель зависимостей
    var dependencyResolver = new AssemblyDependencyResolver(assemblyPath);

    // Логика проверки безопасности
    ...

    // Получаем список всех зависимостей сборки
    foreach (var reference in assembly.MainModule.AssemblyReference)
    {
      // Получаем путь к зависимости с помощью Resolver'a
      var resolvedPath = dependencyResolver.ResolveAssemblyToPath(reference)

      // Если зависимость была найдена - проверяем ее на безопасность
      // (вызываем рекурсию).
      if (resolvedPath is not null)
        return CheckSafety(resolvedPath;)
    }

    return true;
  }
}

2. Уязвимость "доверенной" сборки

Эта уязвимость родилась после устранения первой. Дело в том, что проверка всех сборок на которые ссылается сборка с плагинами - очень неэффективная идея. Сборка ссылается на огромное множество стандартных библиотек .NET, и анализировать их бессмысленно - в них не может быть вредоносного кода.

Поэтому я создал механизм, который определяет, является ли сборка доверенной. Если сборка доверенная - она не проверяется системой безопасности.

Примечание

Я долго думал, стоит ли добавлять эту уязвимость в этот список, поскольку я прекрасно осознавал ее существование при реализации механизма - это скорее была временная мера. И все-таки я решил ее сюда добавить - чтобы показать как делать не надо.

Детали уязвимости

Уязвимость заключается в "дырявости" механизма проверки на доверенность. Дело в том, что изначально он просто проверял, начинается ли имя сборки с System. или Microsoft..

Вот как примерно выглядел метод проверки на доверенность:

private bool IsTrustedAssembly(string name)
{
  return name.StartsWith("System.", StringComparison.OrdinalIgnoreCase) ||
    name.StartsWith("Microsoft.", StringComparison.OrdinalIgnoreCase) ||
    name.Equals("PluginAPI", StringComparison.OrdinalIgnoreCase) ||
    name == "System" || name == "mscorlib" || name == "netstandard";
}

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

Опасность уязвимости

Я бы оценил опасность этой уязвимости на 3.5/5, так как она позволяет пропустить проверку безопасности сборки - а это позволяет запихнуть в нее все что угодно. Однако, если представить что мой менеджер плагинов это инструмент без открытого исходного кода - злоумышленнику нужно знать как реализован механизм проверки доверенности, да и в целом знать о том, существует ли такой механизм вообще.

Устранение

Для устранения этой уязвимости был полностью изменен механизм проверки доверенности. Теперь он проверяет не имя сборки, а ее public token. В компонент был добавлен список доверенных токенов - токенов которыми Microsoft подписывают свои .NET сборки.

Реализация механизма получилась очень простой:

// Список доверенных public токенов
private readonly HashSet<string> _trustedTokens = new()
{
  "b03f5f7f11d50a3a",
  "7cec85d7bea7798e",
  "2c2e8d52f28b9f5e"
};

// Метод для проверки доверенности - вытягивает из AssemblyName публичный токен
// и проверяет, является ли сборка достоверной.
private bool IsTrustedAssembly(AssemblyNameReference reference)
{
  var publicKey = BitConverter.ToString(reference.PublicKeyToken).Replace("-","").ToLowerInvariant();
  return _trustedTokens.Contains(publicKey);
}

Итог

За время работы над системой безопасности я прошел путь от планирования до полноценной реализации. Главное чему меня научил этот проект - как смотреть на решение не только с точки зрения функциональности, но и с точки зрения потенциальных уязвимостей.

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

Конечно я понимаю, что в системе все еще остается пространство для улучшений - однако потребности моего менеджера плагинов она полностью покрывает.

Спасибо за внимание к моему опыту! Буду рад любой обратной связи и идеям, как можно развить систему дальше.