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

Риски десериализации в использовании 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 полностью возлагается на потребителя. Если вы планируете использовать её, следует оценить последствия с точки зрения безопасности, технической стороны, репутации, юридических и нормативных аспектов.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

См. также

  • Last updated on