Поделиться через

Риски десериализации в использовании BinaryFormatter и связанных типов

  • Статья

Эта статья относится к следующим типам:

Эта статья применяется к следующим реализациям .NET:

  • Все версии .NET Framework
  • .NET Core 2.1 – 3.1
  • .NET 5 и более поздней версии

Внимание

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

Примечание.

Начиная с .NET 9 реализация в поле BinaryFormatter создает исключения для использования, даже с параметрами, которые ранее включили его использование. Эти параметры также удаляются. Дополнительные сведения см. в руководстве по миграции BinaryFormatter.

Уязвимости десериализации

Уязвимости десериализации относятся к категории угроз, связанных с небезопасной обработкой полезных данных запроса. Использующие такие уязвимости злоумышленники могут провести на целевое приложение атаки, приводящие к отказу в обслуживании, раскрытию информации или удаленному выполнению кода в нем. Риски этой категории отнесены к 10 основным угрозам в рамках открытого проекта безопасности веб-приложений (OWASP). В качестве целевых могут выступать приложения, написанные на самых разных языках, включая C/C++, Java и C#.

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

Для простоты можно привести следующую аналогию: вызов BinaryFormatter.Deserialize в отношении полезной нагрузки эквивалентен интерпретации такой нагрузки как автономного исполняемого файла и его запуску.

Уязвимости безопасности BinaryFormatter

Предупреждение

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

Тип BinaryFormatter был реализован еще до того, как были четко определены угрозы, связанные с уязвимостями десериализации. Соответственно, его код не соответствует современным рекомендациям. Таким образом, злоумышленники могут использовать метод Deserialize для проведения атак типа "отказ в обслуживании" на использующее его приложение. В случае успешного проведения подобных атак приложение может перестать отвечать, а также может произойти непредвиденное завершение процесса. Обратите внимание, что предотвратить атаки этой категории с помощью SerializationBinder или любого другого параметра конфигурации BinaryFormatter невозможно. В .NET такое поведение считается преднамеренным и не приводит к изменению поведения в результате обновления кода.

Метод BinaryFormatter.Deserialize также может быть уязвим для атак других категорий, например, ведущих к раскрытию информации или удаленному выполнению кода. При этом в достаточной степени снизить соответствующие риски с помощью таких функций, как пользовательский класс SerializationBinder, не всегда возможно. Кроме того, существует вероятность выявления новых уязвимостей, для которых будет невозможна своевременная публикация обновлений системы безопасности .NET. Мы рекомендуем всем потребителям проанализировать особенности конкретных сценариев применения и оценить их уязвимость в отношении этих рисков.

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

Рекомендуемые альтернативы

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

Опасные альтернативные варианты

Не рекомендуется использовать следующие сериализаторы:

Все описываемые выше сериализаторы выполняют неограниченную полиморфную десериализацию и, как и BinaryFormatter, являются небезопасными.

Риски, связанные с необоснованным доверием данным

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

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

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

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

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

Рассмотрим приложение, для которого классическая модель установки заменяется облачной. Например, этот сценарий может включать в себя классические приложения, для которых осуществляется переход к модели полнофункционального клиента или веб-приложения. Модели угроз, характерные для классических приложений, не обязательно будут относиться к облачным службам. Модель угроз для классического приложения может закрыть данную угрозу как "не интересную для клиента, чтобы атаковать себя". Но эта же угроза может стать интересной, когда он рассматривает удаленного пользователя (клиента), атакующего саму облачную службу.

Примечание.

В общем смысле сериализация предназначена для передачи объекта в приложение или из него. В рамках моделирования угроз подобные операции передачи данных почти всегда рассматриваются как пересекающие границу доверия.

См. также