Sicherheit beim Remoting

Dieses Thema bezieht sich auf eine veraltete Technologie, die zum Zwecke der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten wird und nicht für die neue Entwicklung empfohlen wird. Verteilte Anwendungen sollten jetzt mit  Windows Communication Foundation (WCF) entwickelt werden.

Als Entwickler von .NET-Remoteanwendungen müssen Sie sich gut mit den Auswirkungen auskennen, die .NET-Remoting im Besonderen und verteilte Anwendungen im Allgemeinen auf die Sicherheit haben. Ohne eine sichere Implementierung könnte jeder eine Methode für das Remoteobjekt aufrufen oder vertrauliche Informationen abfangen, während diese an ein oder von einem Remoteobjekt gesendet werden. Damit dies nicht passiert, müssen Sie Clients (und möglicherweise auch Server) authentifizieren und die Kommunikation zwischen beiden verschlüsseln.

Es gibt aber auch komplexere Probleme. Nehmen Sie ein Remoteobjekt als Beispiel, das eine Methode definiert, die einen Delegaten als Parameter annimmt. Ein böswilliger Entwickler könnte die Serveranwendung über den Delegaten zwingen, jeden gewünschten Code auszuführen. Wenn ein Delegat eine statische Methode einschließt, werden Aufrufe für diesen Delegaten nicht remote ausgeführt; der Code wird in der Anwendungsdomäne aufgerufen, die den Delegaten aufgerufen hat. So könnte z. B. ein nicht autorisierter Client diese Sicherheitslücke nutzen, um das Remoteobjekt aufzurufen und einen Delegaten zu übergeben, der eine statische Methode enthält. Die Assembly, die die statische Methode implementiert, kann auf den Server kopiert werden, und wenn der Delegat aufgerufen wird, würde die statische Methode auf dem Server ausgeführt. Um dies zu verhindern, müssen Sie stets Delegaten deklarieren, die in Remoteobjekten mit benutzerdefinierten Typen und Parametern verwendet werden, die von Hackern nicht erraten werden können. Außerdem sollten Sie einem Client niemals erlauben, einen Typ zu definieren und an das zu deserialisierende Remoteobjekt zu übergeben.

In diesem Abschnitt werden die verschiedenen Sicherheitsansätze auf der Grundlage bestimmter Designentscheidungen beschrieben. Nicht alle Szenarien werden hier behandelt, diese Themen sind jedoch ein guter Ausgangspunkt.

Codezugriffssicherheit

Mithilfe der Codezugriffssicherheit wird der Zugriff von Code auf geschützte Ressourcen und Operationen beschränkt. Wenn Code versucht, auf eine geschützte Ressource zuzugreifen, wird in der Regel über einen Stackwalk sichergestellt, dass alle Stapelrahmen auf die Ressource zugreifen dürfen. Beim Aufruf eines Remoteobjekts wird dieser Stackwalk nicht über die Remotegrenze hinweg durchgeführt. Die Remoteinfrastruktur benötigt folglich eine FullTrust-Berechtigung, um entweder auf dem Client oder auf dem Server ausgeführt zu werden. FullTrust-Berechtigungen deaktivieren im Wesentlichen die Codezugriffssicherheit. Jede nicht autorisierte Verwendung einer Remoteanwendung stellt einen nicht autorisierten Zugriff auf FullTrust-Berechtigungen bereit.

9hwst9th.note(de-de,VS.100).gifHinweis:
Mehrere Systemtypen erweitern MarshalByRefObject, führen zur Laufzeit aber auch Sicherheitsüberprüfungen durch, um zu verhindern, dass irgendetwas außerhalb der Anwendungsdomäne ein Objekt dieses Typs remote aufrufen kann. AppDomain und System.Windows.Forms.Form sind zwei Beispiele für solche Systemtypen.

Sicherheitsüberlegungen in Remoteanwendungen

Im Allgemeinen gibt es zwei Sicherheitsbereiche, die in einer verteilten Anwendung berücksichtigt werden müssen: der Schutz des Kommunikationschannels und der Schutz der Anwendung vor einer unzulässigen Nutzung.

Beim Schutz des Kommunikationschannels muss unter anderem sichergestellt werden, dass die Nachrichten verschlüsselt und bei der Übertragung nicht geändert werden. Der Schutz einer Anwendung umfasst die Authentifizierung und Autorisierung von Aufrufern. Beim Authentifizieren eines Aufrufers wird überprüft, ob der Aufrufer auch der Aufrufer ist, den er zu sein vorgibt. Bei der Autorisierung eines Aufrufers wird überprüft, ob der Aufrufer die Berechtigungen besitzt, die für einen bestimmten Aufruf oder für den Zugriff auf eine erforderliche Ressource erforderlich sind.

Die integrierten Channels bieten folgende Unterstützung hinsichtlich der Sicherheit:

HttpChannel – Unterstützt eine Authentifizierung nur, wenn Remoteobjekte von Internetinformationsdiensten (IIS) gehostet werden. Verschlüsselung wird nur unterstützt, wenn IIS für die Verwendung von SSL konfiguriert ist.

TcpChannel – Unterstützt Authentifizierung und Verschlüsselung.

IpcChannel – Unterstützt Authentifizierung.

9hwst9th.note(de-de,VS.100).gifHinweis:
Autorisierung wird im Code bereitgestellt. Die integrierten Channels können Ihnen dies nicht zur Verfügung stellen, weil sie nicht wissen, was der Code macht und welche Einschränkungen Sie festgelegt haben.

9hwst9th.Caution(de-de,VS.100).gifVorsicht:
.NET Framework-Remoting führt standardmäßig keine Authentifizierung oder Verschlüsselung durch. Daher empfiehlt es sich, vor der Remoteinteraktion mit Clients und Servern alle erforderlichen Schritte zu unternehmen, um die Identität der Clients oder Server sicherzustellen. Da .NET Framework-Remoteanwendungen FullTrust-Berechtigungen zur Ausführung benötigen, könnte ein nicht autorisierter Client Code so ausführen, als ob er voll vertrauenswürdig wäre, wenn dem Client Zugriff auf Ihren Server gewährt würde. Authentifizieren Sie die Clients unbedingt, und verschlüsseln Sie die Kommunikationsstreams.

Siehe auch

Verweis

RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices

Konzepte

Authentifizierung mit dem HTTP-Channel

Weitere Ressourcen

Übersicht über .NET Framework-Remoting