Weitere Überlegungen zur Sicherheit in Windows Forms

  • Artikel

.NET Framework-Sicherheitseinstellungen können möglicherweise dazu führen, dass Ihre Anwendung anders als in einer teilweise vertrauenswürdigen Umgebung als auf dem lokalen Computer ausgeführt wird. .NET Framework beschränkt den Zugriff auf wichtige lokale Ressourcen, beispielsweise unter anderem das Dateisystem, Netzwerk und nicht verwaltete APIs. Die Sicherheitseinstellungen haben Auswirkung auf die Möglichkeit zum Aufruf der Windows-API von Microsoft oder andere APIs, die nicht vom Sicherheitssystem überprüft werden können. Sicherheit wirkt sich auch auf andere Aspekte der Anwendung aus, einschließlich des Datei-und Datenzugriffs und des Druckens. Weitere Informationen zum Zugriff auf Dateien und Daten in einer teilweise vertrauenswürdigen Umgebung finden Sie unter Mehr Sicherheit beim Datei- und Datenzugriff in Windows Forms. Weitere Informationen zum Drucken in einer teilweise vertrauenswürdigen Umgebung 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 Windows-API über Anwendungen, die in einer teilweise vertrauenswürdigen Umgebung ausgeführt werden, erläutert.

Zugriff auf die Zwischenablage

Die Klasse UIPermission steuert den Zugriff auf die Zwischenablage, und die zugehörige Enumeration UIPermissionClipboard gibt die Zugriffsebene an. Die folgende Tabelle enthält die möglichen Berechtigungsebenen.

UIPermissionClipboard-Wert BESCHREIBUNG
AllClipboard Die Zwischenablage kann ohne Einschränkung verwendet werden.
OwnClipboard Die Zwischenablage kann mit einigen Einschränkungen verwendet werden. Die Möglichkeit zum Einfügen von Daten in der Zwischenablage (Befehlsvorgang „Kopieren“ oder „Ausschneiden“) ist nicht eingeschränkt. Systeminterne Steuerelemente, die das Einfügen zulassen (z.B. von einem Textfeld), können Daten aus der Zwischenablage annehmen, Benutzersteuerelemente jedoch können nicht programmgesteuert aus der Zwischenablage gelesen werden.
NoClipboard Die Zwischenablage kann nicht verwendet werden.

Standardmäßig erhält die lokale Intranetzone AllClipboard-Zugriff, und die Internetzone erhält OwnClipboard-Zugriff. Dies bedeutet, dass die Anwendung zwar Daten in die Zwischenablage kopieren kann, sie kann jedoch keine Daten programmgesteuert in die Zwischenablage einfügen oder aus der Zwischenablage lesen. Diese Einschränkungen verhindern, dass Programme ohne volle Vertrauenswürdigkeit auf Inhalte, die von einer anderen Anwendung in die Zwischenablage kopiert wurden, gelesen werden können. Wenn Ihre Anwendung vollständigen Zugriff auf die Zwischenablage benötigt, aber Sie nicht über die Berechtigungen verfügen, müssen Sie die Berechtigungen für Ihre Anwendung erhöhen. Weitere Informationen zum Erhöhen von Berechtigungen finden Sie unter Allgemeine Verwaltung der Sicherheitsrichtlinien.

Fensterbearbeitung

Die Klasse UIPermission steuert auch die Berechtigung zur Durchführung von Fensterbearbeitung und anderen UI-bezogenen Aktionen, und die zugehörige Enumeration UIPermissionWindow gibt die Zugriffsebene an. Die folgende Tabelle enthält die möglichen Berechtigungsebenen.

Standardmäßig erhält die lokale Intranetzone AllWindows-Zugriff, und die Internetzone erhält SafeTopLevelWindows-Zugriff. Dies bedeutet, dass die Anwendung in der Internetzone die meisten Fenster- und Benutzeroberflächenaktionen ausführen kann, die Darstellung des Fensters jedoch wird geändert. Das geänderte Fenster zeigt bei Erstausführung eine Sprechblase an, enthält geänderten Titelleistentext und erfordert die Schaltfläche „Schließen“ in der Titelleiste. Die Sprechblase und die Titelleiste zeigen dem Benutzer der Anwendung an, dass die Anwendung mit teilweiser Vertrauenswürdigkeit ausgeführt wird.

UIPermissionWindow-Wert BESCHREIBUNG
AllWindows Benutzer können alle Fenster und Benutzereingabeereignisse uneingeschränkt verwenden.
SafeTopLevelWindows Benutzer können nur sicherere übergeordnete und sicherere untergeordnete Fenster zum Zeichnen verwenden, und sie können nur Benutzereingabeereignisse in diesen über- und untergeordneten Fenstern für die Benutzeroberfläche verwenden. Diese Safer sind deutlich gekennzeichnet und weisen minimale und maximale Größenbeschränkungen auf. Die Einschränkungen verhindern potenziell schädliche Spoofingangriffe, z.B. das Imitieren von Anmeldebildschirmen des Systems oder des System-Desktops und schränken den programmgesteuerten Zugriff auf übergeordnete Fenster, fokusbezogene APIs sowie die Verwendung des ToolTip-Steuerelements ein.
SafeSubWindows Benutzer können nur sicherere untergeordnete Fenster zum Zeichnen verwenden, und sie können 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 Benutzer können nicht willkürlich Fenster oder Benutzeroberflächenereignisse verwenden. Es kann keine Benutzeroberfläche verwendet werden.

Auf jeder Berechtigungsebene, die durch die UIPermissionWindow-Enumeration identifiziert wird, sind weniger Aktionen zugelassen als in der Ebene darüber. In den folgenden Tabellen sind die Aktionen aufgeführt, die durch die Werte SafeTopLevelWindows und SafeSubWindows eingeschränkt sind. Die genauen Berechtigungen, die für jedes Mitglied erforderlich sind, finden Sie im Verweis für das Mitglied in der Dokumentation zur .NET Framework-Klassenbibliothek.

SafeTopLevelWindows Berechtigung schränkt die in der folgenden Tabelle aufgeführten Aktionen ein.

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 kein untergeordnetes Element des aufrufenden Steuerelements ist.
– Ändern des Steuerelementfokus innerhalb eines Containersteuerelements.
Cursor – Festlegen der Clip-Eigenschaft.
– Aufrufen der Hide-Methode.
DataGrid – Aufrufen der ProcessTabKey-Methode.
Form – Abrufen der Eigenschaft ActiveForm oder MdiParent.
– Festlegen der Eigenschaft ControlBox, ShowInTaskbar oder TopMost.
– Festlegen der Opacity-Eigenschaft auf unter 50 %.
– Programmgesteuertes Festlegen der Eigenschaft WindowState auf Minimized.
– Aufrufen der Activate-Methode.
– Verwenden der None, FixedToolWindow und SizableToolWindowFormBorderStyle-Enumerationswerte.
NotifyIcon – Die Verwenden der Komponente NotifyIcon ist vollständig eingeschränkt.

Der Wert SafeSubWindows schränkt die in der folgenden Tabelle aufgeführten Aktionen ein, zusätzlich zu den durch den SafeTopLevelWindows-Wert festgelegten Einschränkungen.

Komponente Eingeschränkte Aktionen
CommonDialog – Anzeige eines von der CommonDialog-Klasse abgeleiteten Dialogfelds.
Control – Aufrufen der CreateGraphics-Methode.
– Festlegen der Cursor-Eigenschaft.
Cursor – Festlegen der Current-Eigenschaft.
MessageBox – Aufrufen der Show-Methode.

Hosten von Steuerelementen von Drittanbietern

Eine andere Art von Fensterbearbeitung kann auftreten, wenn in Ihren Formularen Steuerelemente von Drittanbietern gehostet werden. Bei dem Steuerelement eines Drittanbieters handelt es sich um ein benutzerdefiniertes UserControl, das Sie nicht selbst entwickelt und kompiliert haben. Obwohl das Hostingszenario nur schwer nutzbar ist, kann das Steuerelement eines Drittanbieters theoretisch seine Renderingoberfläche über den gesamten Bereich Ihres Formulars erweitern. Dieses Steuerelement könnte dann ein wichtiges Dialogfeld imitieren und Informationen wie Kombinationen aus Benutzername und Kennwort oder Bankkontonummern von Benutzern anfordern.

Verwenden Sie zur Einschränkung dieses möglichen Risikos Steuerelemente von Drittanbietern nur von Anbietern, denen Sie vertrauen können. Wenn Sie Steuerelemente von Drittanbietern verwenden, die Sie von einer nicht überprüfbaren Quelle heruntergeladen haben, wird empfohlen, dass Sie den Quellcode auf mögliche Exploits überprüfen. Nachdem Sie sichergestellt haben, dass die Quelle nicht bösartig ist, sollten Sie die Assembly selbst kompilieren, um sicherzustellen, dass die Quelle der Assembly entspricht.

Windows-API-Aufrufe

Wenn der Anwendungsentwurf das Aufrufen einer Funktion über die Windows-API erforderlich macht, greifen Sie auf nicht verwaltete Codes zu. In diesem Fall können die Aktionen des Codes für das Fenster oder das Betriebssystem nicht bestimmt werden, wenn Sie mit Windows-API-Aufrufen oder -Werten arbeiten. Die Klasse SecurityPermission und der Wert UnmanagedCode der Enumeration SecurityPermissionFlag steuern den Zugriff auf nicht verwalteten Code. Eine Anwendung kann nur dann auf nicht verwalteten Code zugreifen, wenn ihr die Berechtigung UnmanagedCode erteilt wurde. Standardmäßig können nur lokal ausgeführte Anwendungen den nicht verwalteten Code aufrufen.

Einige Windows Forms-Mitglieder bieten nicht verwalteten Zugriff, der die UnmanagedCode-Berechtigung erfordert. Die folgende Tabelle enthält die Member im System.Windows.Forms-Namespace, für die die Berechtigung erforderlich ist. Weitere Informationen zu den Berechtigungen, die für ein Member erforderlich sind, 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 keine Berechtigung zum Aufrufen nicht verwalteter Codes hat, muss Ihre Anwendung eine UnmanagedCode-Berechtigung anfordern, oder Sie müssen alternative Methoden für die Implementierung von Features in Erwägung ziehen; in vielen Fällen stellt Windows Forms eine verwaltete Alternative zu Windows-API-Funktionen bereit. Wenn keine Alternativen vorhanden sind und die Anwendung auf einen nicht verwalteten Code zugreifen muss, müssen Sie die Berechtigungen für die Anwendung erhöhen.

Mit der Berechtigung zum Aufrufen eines nicht verwalteten Codes kann eine Anwendung nahezu jede Aktion ausführen. Aus diesem Grund sollte die Berechtigung zum Aufrufen eines nicht verwalteten Codes nur für Anwendungen erteilt werden, die aus einer vertrauenswürdigen Quelle stammen. Alternativ, abhängig von der Anwendung, könnte der Teil der Anwendungsfunktionalität, über den der nicht verwaltete Code aufgerufen wird, optional sein oder nur in einer vollständig vertrauenswürdigen Umgebung aktiviert werden. Weitere Informationen zu problematischen Berechtigungen finden Sie unter Problematische Berechtigungen und Richtlinienverwaltung. Weitere Informationen zum Erhöhen von Berechtigungen finden Sie unter Allgemeine Verwaltung der Sicherheitsrichtlinien.

Weitere Informationen