Безопасность удаленного взаимодействия

Этот раздел относится к технологии прежних версий, которая сохраняется для обеспечения обратной совместимости с существующими приложениями и не рекомендуется для разработки новых приложений. Сейчас распределенные приложения следует создавать с помощью  Windows Communication Foundation (WCF).

Разработчики приложений удаленного взаимодействия .NET должны хорошо понимать проблемы безопасности, связанные не только с удаленным взаимодействием .NET, но и с распределенными приложениями в целом. Без учета вопросов безопасности при реализации любой злоумышленник может вызвать метод разрабатываемого удаленного объекта или перехватить конфиденциальные сведения, передаваемые удаленному объекту или удаленным объектом. Чтобы избежать этого, необходимо проверять подлинность клиентов (и, возможно, серверов) и шифровать данные, которыми они обмениваются.

Имеются и менее очевидные проблемы. Представьте себе удаленный объект, в котором определен метод, принимающий в качестве параметра делегат. Разработчик-злоумышленник может использовать этот делегат, чтобы заставить серверное приложение выполнять любой сторонний код. Если делегат выступает в роли оболочки статического метода, все вызовы этого делегата не передаются в удаленную систему; код вызывается в домене приложения, вызвавшего этот делегат. Поддельный клиент может воспользоваться этой уязвимостью, чтобы, например, вызвать удаленный объект и передать делегат, являющийся оболочкой статического метода. Сборку, которая реализует статический метод, можно скопировать на сервер, и после вызова делегата статический метод будет выполнен на сервере. Чтобы защититься от этого, следует всегда объявлять используемые в удаленных объектах делегаты с помощью пользовательских типов и параметров, которые не удастся угадать злоумышленникам. Кроме тогда, клиент никогда не должен определять и передавать удаленному объекту тип, который нужно будет десериализовать.

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

Управление доступом для кода

Управление доступом для кода — это механизм, позволяющий ограничить доступ кода к защищенным ресурсам и операциям. Обычно при попытке кода получить доступ к защищенному ресурсу выполняется проверка стека, чтобы удостовериться, что у кадров стека имеется разрешение на доступ к ресурсу. При вызове удаленного объекта проверка стека не выполняется за пределами границ участника удаленного взаимодействия. Поэтому инфраструктура удаленного взаимодействия требует наличия разрешения FullTrust на выполнение у клиента или у сервера. Наличие разрешения FullTrust отключает функцию управления доступом для кода. При неавторизованном использовании приложения удаленного взаимодействия предоставляется неавторизованный доступ к разрешениями FullTrust.

Примечание
Несколько системных типов расширяют объект MarshalByRefObject, но они также выполняют проверку безопасности во время выполнения, чтобы не допустить удаленный вызов объекта данного типа объектами, находящимися за пределами домена приложения. Два примера таких типов — AppDomain и System.Windows.Forms.Form.

Вопросы безопасности в отношении приложений удаленного взаимодействия

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

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

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

HttpChannel — поддерживает проверку подлинности, только если удаленные объекты размещаются в службах IIS. Шифрование поддерживается, только если службы IIS настроены на использование SSL.

TcpChannel — поддерживает проверку подлинности и шифрование.

IpcChannel — поддерживает проверку подлинности.

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

Внимание!

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

См. также

Справочник

RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices

Основные понятия

Проверка подлинности для канала HTTP

Другие ресурсы

Общие сведения о средствах удаленного взаимодействия платформы .NET Framework