Weitere Überlegungen zur Sicherheit in Windows Forms
Aktualisiert: November 2007
Durch die Sicherheitseinstellungen von .NET Framework wird Ihre Anwendung in einer Umgebung mit teilweiser Vertrauenswürdigkeit möglicherweise anders ausgeführt als auf dem lokalen Computer. Mit .NET Framework wird der Zugriff auf wichtige lokale Ressourcen, beispielsweise das Dateisystem, das Netzwerk und nicht verwaltete APIs, beschränkt. Die Sicherheitseinstellungen wirken sich auf die Aufrufmöglichkeiten der Microsoft Win32-API oder anderer APIs aus, die vom Sicherheitssystem nicht identifiziert werden können. Darüber hinaus werden weitere Aspekte der Anwendung beeinflusst, z. B. der Datei- und Datenzugriff und das Drucken. Weitere Informationen über Datei- und Datenzugriff in einer Umgebung mit teilweiser Vertrauenswürdigkeit finden Sie unter Mehr Sicherheit beim Datei- und Datenzugriff in Windows Forms. Weitere Informationen über das Drucken in einer Umgebung mit teilweiser Vertrauenswürdigkeit finden Sie unter Mehr Sicherheit beim Drucken in Windows Forms.
In den folgenden Abschnitten wird das Arbeiten mit der Zwischenablage, das Bearbeiten von Fenstern und das Aufrufen der Win32-API aus Anwendungen in einer Umgebung mit teilweiser Vertrauenswürdigkeit erläutert.
Zugriff auf die Zwischenablage
Die UIPermission-Klasse steuert den Zugriff auf die Zwischenablage. Der zugeordnete UIPermissionClipboard-Enumerationswert gibt die Zugriffsebene an. In der folgenden Tabelle sind die möglichen Berechtigungsebenen aufgeführt.
UIPermissionClipboard-Wert |
Beschreibung |
|---|---|
Die Zwischenablage kann ohne Einschränkungen verwendet werden. |
|
Die Zwischenablage kann mit einigen Einschränkungen verwendet werden. Das Ablegen von Daten in der Zwischenablage (die Befehle zum Kopieren oder Ausschneiden) ist uneingeschränkt möglich. Systeminterne Steuerelemente wie Textfelder, bei denen das Einfügen möglich ist, können Daten aus der Zwischenablage entgegennehmen. Benutzersteuerelemente können jedoch nicht programmgesteuert aus der Zwischenablage lesen. |
|
Die Zwischenablage kann nicht verwendet werden. |
In der Standardeinstellung erhält die Zone Lokales Intranet Zugriff auf AllClipboard und die Zone Internet Zugriff auf OwnClipboard. Dies bedeutet, dass die Anwendung zwar Daten in die Zwischenablage kopieren, diese jedoch nicht programmgesteuert einfügen oder aus der Zwischenablage lesen kann. Diese Einschränkungen sollen verhindern, dass nicht voll vertrauenswürdige Programme Inhalte lesen, die von anderen Anwendungen in die Zwischenablage kopiert wurden. Wenn für die Anwendung der uneingeschränkte Zugriff auf die Zwischenablage erforderlich ist, Sie jedoch nicht über die entsprechenden Berechtigungen verfügen, müssen Sie die Berechtigungen für die Anwendung erhöhen. Weitere Informationen zum Erhöhen von Berechtigungen finden Sie unter Allgemeine Verwaltung der Sicherheitsrichtlinien.
Bearbeiten von Fenstern
Die UIPermission-Klasse steuert auch die Berechtigungen zum Ändern von Fenstern sowie für andere Aktionen auf der Benutzeroberfläche. Der verknüpfte UIPermissionWindow-Enumerationswert gibt die Zugriffsebene an. In der folgenden Tabelle sind die möglichen Berechtigungsebenen aufgeführt.
In der Standardeinstellung erhält die Zone Lokales Intranet Zugriff auf AllWindows und die Zone Internet Zugriff auf SafeTopLevelWindows. In der Internetzone können von der Anwendung somit die meisten Fenster- und Benutzeroberflächenaktionen ausgeführt werden, die Darstellung des Fensters wird jedoch geändert. Das geänderte Fenster zeigt beim ersten Ausführen einen Hinweis in einer Sprechblase an und enthält geänderten Titelleistentext. Außerdem ist auf der Titelleiste eine Schaltfläche zum Schließen erforderlich. Durch die Sprechblase und in der Titelleiste wird dem Benutzer der Anwendung signalisiert, dass die Anwendung mit teilweiser Vertrauenswürdigkeit ausgeführt wird.
UIPermissionWindow-Wert |
Beschreibung |
|---|---|
Die Benutzer können alle Fenster und Benutzereingabeereignisse ohne Einschränkungen verwenden. |
|
Die Benutzer können nur sicherere übergeordnete und untergeordnete Fenster zum Zeichnen verwenden. Außerdem können in diesen übergeordneten und untergeordneten Fenstern nur die Benutzereingabeereignisse der Benutzeroberfläche verwendet werden. Diese sichereren Fenster sind eindeutig gekennzeichnet und weisen Beschränkungen hinsichtlich der minimalen und maximalen Größe auf. Durch die Beschränkungen werden potenziell schädliche Spoofing-Angriffe wie das Imitieren von Bildschirmen zur Systemanmeldung oder des Systemdesktops vermieden. Der programmgesteuerte Zugriff auf übergeordnete Fenster, fokusbezogene APIs und die Verwendung des ToolTip-Steuerelements werden eingeschränkt. |
|
Die Benutzer können nur sicherere untergeordnete Fenster zum Zeichnen und nur Benutzereingabeereignisse für die Benutzeroberfläche in diesem untergeordneten Fenster verwenden. Ein in einem Browser angezeigtes Steuerelement ist ein Beispiel für ein sichereres untergeordnetes Fenster. |
|
Die Benutzer können keine Fenster oder Benutzeroberflächenereignisse verwenden. Benutzeroberflächen können nicht verwendet werden. |
Jede Berechtigungsebene, die von der UIPermissionWindow-Enumeration angegeben wird, ermöglicht weniger Aktionen als die jeweils übergeordnete Berechtigungsebene. In den folgenden Tabellen sind die Aktionen aufgelistet, die durch die Werte SafeTopLevelWindows und SafeSubWindows beschränkt werden. Die genauen Berechtigungen, die für die einzelnen Member erforderlich sind, finden Sie im Referenzthema des jeweiligen Members in der Dokumentation zur .NET Framework-Klassenbibliothek.
Durch die SafeTopLevelWindows-Berechtigung werden die in der folgenden Tabelle aufgeführten Aktionen beschränkt:
Komponente |
Eingeschränkte Aktionen |
|---|---|
|
|
|
|
|
|
|
|
|
Zusätzlich zu den Einschränkungen durch den SafeTopLevelWindows-Wert werden durch den SafeSubWindows-Wert die in der folgenden Tabelle aufgelisteten Aktionen beschränkt.
Komponente |
Eingeschränkte Aktionen |
|---|---|
|
|
|
|
|
|
|
Hosten von Drittanbietersteuerelementen
Eine weitere Art der Fenstermanipulation kann auftreten, wenn in Ihren Formularen Steuerelemente von Drittanbietern enthalten sind. Jedes benutzerdefinierte UserControl, das Sie nicht selbst entwickelt und kompiliert haben, ist ein Steuerelement eines Drittanbieters. Obwohl in diesem Hostingszenario kaum auszunutzende Sicherheitslücken vorhanden sind, kann ein Steuerelement eines Drittanbieters seine Darstellungsoberfläche auf den gesamten Formularbereich erweitern. Das Steuerelement kann dann ein wichtiges Dialogfeld imitieren, in dem Benutzer zur Eingabe Ihrer Benutzernamen und Kennwörter sowie Bankverbindungsdaten aufgefordert werden.
Verringern Sie dieses Risiko, indem Sie ausschließlich Steuerelemente von vertrauenswürdigen Anbietern verwenden. Wenn Sie Steuerelemente von Drittanbietern aus nicht überprüfbaren Quellen downloaden und verwenden, wird das Überprüfen des Quellcodes auf mögliche Sicherheitsrisiken empfohlen. Wenn Sie sich vergewissert haben, dass es sich nicht um böswilligen Quellcode handelt, sollten Sie die Assembly selbst kompilieren, um sicherzustellen, dass der Quellcode mit der Assembly übereinstimmt.
Win32 API-Aufrufe
Wenn für Ihren Anwendungsentwurf das Aufrufen einer Funktion aus der Win32-API erforderlich ist, greifen Sie auf nicht verwalteten Code zu. In diesem Fall können die Aktionen des Codes im Fenster oder im Betriebssystem bei der Arbeit mit Win32-API-Aufrufen und -Werten nicht ermittelt werden. Die SecurityPermission-Klasse und der UnmanagedCode-Wert der SecurityPermissionFlag-Enumeration steuern den Zugriff auf nicht verwalteten Code. Eine Anwendung kann nur auf nicht verwalteten Code zugreifen, wenn ihr die UnmanagedCode-Berechtigung gewährt wurde. In der Standardeinstellung kann nicht verwalteter Code nur von lokal ausgeführten Anwendungen aufgerufen werden.
Einige Windows Forms-Member bieten nicht verwalteten Zugriff, der die UnmanagedCode-Berechtigung erfordert. In der folgenden Tabelle sind die Member im System.Windows.Forms-Namespace aufgelistet, für die diese Berechtigung erforderlich ist. Weitere Informationen zu den für einen Member erforderlichen Berechtigungen finden Sie in der Dokumentation zur .NET Framework-Klassenbibliothek.
Komponente |
Member |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn Ihre Anwendung nicht zum Aufrufen von nicht verwaltetem Code berechtigt ist, muss von der Anwendung die UnmanagedCode-Berechtigung angefordert werden, oder Sie müssen Features eventuell auf andere Weise implementieren. In vielen Fällen bietet Windows Forms eine verwaltete Alternative zu Win32-API-Funktionen. Wenn es keine anderen Möglichkeiten gibt und die Anwendung auf nicht verwalteten Code zugreifen muss, müssen Sie die Berechtigungen für die Anwendung erhöhen.
Mit einer Berechtigung zum Aufrufen von nicht verwaltetem Code kann eine Anwendung nahezu jede Aktion ausführen. Daher sollte eine solche Berechtigung nur Anwendungen gewährt werden, die aus einer vertrauenswürdigen Quelle stammen. Je nach Anwendung können Sie den Teil der Anwendungsfunktionalität, der nicht verwalteten Code aufruft, auch optional gestalten oder nur in voll vertrauenswürdiger Umgebung aktivieren. Weitere Informationen zu problematischen Berechtigungen finden Sie unter Problematische Berechtigungen und Richtlinienverwaltung. Weitere Informationen zur Erhöhung von Berechtigungen finden Sie unter Allgemeine Verwaltung der Sicherheitsrichtlinien.
Siehe auch
Konzepte
Mehr Sicherheit beim Datei- und Datenzugriff in Windows Forms
Mehr Sicherheit beim Drucken in Windows Forms
Übersicht über die Sicherheit in Windows Forms
ClickOnce-Bereitstellung und Sicherheit