Weitere Überlegungen zur Sicherheit in Windows Forms

Artikel
08/10/2011

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
AllClipboard	Die Zwischenablage kann ohne Einschränkungen verwendet werden.
OwnClipboard	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.
NoClipboard	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
AllWindows	Benutzer können alle Fenster und Benutzereingabeereignisse ohne Einschränkung verwenden.
SafeTopLevelWindows	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.
SafeSubWindows	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.
NoWindows	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
Application	Festlegen der SafeTopLevelCaptionFormat-Eigenschaft.
Control	Abrufen der Parent-Eigenschaft. Festlegen der Region-Eigenschaft. Aufrufen von FindForm, Focus, FromChildHandle und FromHandle, PreProcessMessage, ReflectMessage oder der SetTopLevel-Methode. Aufrufen der GetChildAtPoint-Methode, wenn das zurückgegebene Steuerelement nicht dem aufrufenden Steuerelement untergeordnet ist. Ändern des Steuerelementfokus innerhalb eines Containersteuerelements.
Cursor	Festlegen der Clip-Eigenschaft. Aufrufen der Hide-Methode.
DataGrid	Aufrufen der ProcessTabKey-Methode.
Form	Abrufen der ActiveForm-Eigenschaft oder der MdiParent-Eigenschaft. Festlegen der ControlBox, ShowInTaskbar-Eigenschaft oder derTopMost-Eigenschaft. Festlegen der Opacity-Eigenschaft auf einen Wert unter 50 %. Programmgesteuertes Festlegen der WindowState-Eigenschaft auf Minimized. Aufrufen der Activate-Methode. Verwenden der Enumerationswerte None, FixedToolWindow, SizableToolWindow und FormBorderStyle.
NotifyIcon	Die Verwendung der NotifyIcon-Komponente ist vollständig beschränkt.

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
CommonDialog	Anzeigen eines Dialogfelds, das von der CommonDialog-Klasse abgeleitet wurde.
Control	Aufrufen der CreateGraphics-Methode. Festlegen der Cursor-Eigenschaft.
Cursor	Festlegen der Current-Eigenschaft.
MessageBox	Aufrufen der Show-Methode.

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 herunterladen 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
Application	AddMessageFilter-Methode CurrentInputLanguage-Eigenschaft Exit-Methode ExitThread-Methode ThreadException-Ereignis
CommonDialog	HookProc-Methode OwnerWndProc-Methode Reset-Methode RunDialog-Methode
Control	CreateParams-Methode DefWndProc-Methode DestroyHandle-Methode WndProc-Methode
Help	ShowHelp-Methoden ShowHelpIndex-Methode
NativeWindow	NativeWindow-Klasse
Screen	FromHandle-Methode
SendKeys	Send-Methode SendWait-Methode

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.