WPF-Sicherheitsstrategie – Plattformsicherheit

Obwohl Windows Presentation Foundation (WPF) eine ganze Reihe von Sicherheitsdiensten bereitstellt, nutzt WPF auch die Sicherheitsfeatures der zugrunde liegenden Plattform. Dazu zählen das Betriebssystem, die CLR und Internet Explorer. Zusammen bieten diese Ebenen für WPF ein starkes, umfassendes Sicherheitsmodell, das jede einzelne Fehlerstelle auszuschließen versucht, wie in der folgenden Abbildung dargestellt.

Im Rest dieses Themas werden die Features auf jeder dieser Ebenen, die sich insbesondere auf WPF beziehen, erläutert.

Dieses Thema enthält folgende Abschnitte.

• Betriebssystemsicherheit
• Sicherheit von Common Language Runtime
• Sicherheit von Microsoft Internet Explorer
• Verwandte Abschnitte

Betriebssystemsicherheit

Für WPF wird mindestens Windows XP SP2 benötigt. Der Kern von Windows XP SP2 bietet mehrere Sicherheitsfeatures, die die Sicherheitsgrundlage für alle Windows-Anwendungen, einschließlich der mit WPF erstellten Anwendungen, ergeben. Windows Vista enthält die Sicherheitsfeatures von WPF und erweitert sie noch. In diesem Thema wird der Umfang der Sicherheitsfeatures erläutert, die für WPF wichtig sind. Außerdem wird die Frage geklärt, wie WPF in diesen Features integriert ist, um einen noch umfassenderen Schutz zu bieten.

Microsoft Windows XP Service Pack 2 (SP2)

Zusätzlich zu einer allgemeinen Beurteilung und einer Erhöhung der Sicherheit von Windows werden in diesem Thema drei Hauptfeatures von Windows XP SP2 erörtert:

• Kompilieren mit der /GS-Option

• Microsoft Windows Update.

Kompilieren mit der /GS-Option

Windows XP SP2 bietet Schutz durch die Neukompilierung von vielen wichtigen Systembibliotheken, einschließlich aller WPF-Abhängigkeiten, z. B. der CLR, um Pufferüberläufe zu vermeiden. Dies wird durch Verwendung des Parameters /GS beim C/C++-Befehlszeilencompiler erreicht. Obwohl Pufferüberläufe explizit vermieden werden sollten, ist das Kompilieren mit der /GS-Option ein Beispiel für einen umfassenden Schutz vor möglichen Schwachstellen, die dadurch versehentlich oder vorsätzlich entstehen.

Immer wieder sind Pufferüberläufe die Ursache vieler Sicherheitslücken mit gravierenden Auswirkungen. Ein Pufferüberlauf findet statt, wenn ein Angreifer eine Schwachstelle im Code ausnutzt, über die das Einfügen von schädlichem Code möglich ist, der außerhalb der Puffergrenzen Schreibvorgänge ausführt. Dadurch kann ein Angreifer dann den Prozess, in dem der Code ausgeführt wird, übernehmen, indem er die Rückgabeadresse einer Funktion überschreibt, damit sein eigener Code ausgeführt wird. Das Ergebnis ist schädlicher Code, der beliebigen Code mit den gleichen Berechtigungen wie der übernommene Prozess ausführt.

Das Compiler-Flag /GS schützt auf hohem Niveau vor einigen möglichen Pufferüberläufen, indem ein spezielles Sicherheitscookie eingefügt wird, um die Rückgabeadresse einer Funktion mit lokalen Zeichenfolgenpuffern zu schützen. Nach der Rückkehr einer Funktion wird das Sicherheitscookie mit seinem vorherigen Wert verglichen. Wenn sich der Wert geändert hat, kann ein Pufferüberlauf stattgefunden haben, und der Prozess wird mit einem Fehlerzustand beendet. Durch das Beenden des Prozesses wird die Ausführung von potenziell schädlichem Code verhindert. Weitere Informationen finden Sie unter /GS (Puffer-Sicherheitsüberprüfung).

WPF wird mit dem Flag /GS kompiliert, um für WPF-Anwendungen eine weitere Schutzebene hinzuzufügen.

Verbesserungen für Microsoft Windows Update

In Windows XP SP2 wurde auch Microsoft Windows Update verbessert, um das Herunterladen und Installieren von Updates zu vereinfachen. Diese Änderungen verbessern die Sicherheit für WPF-Kunden beträchtlich, indem sichergestellt wird, dass ihre Systeme aktuell sind, insbesondere im Hinblick auf Sicherheitsupdates.

Windows Vista

WPF-Benutzer unter Windows Vista profitieren von den zusätzlichen Sicherheitsverbesserungen des Betriebssystems. Dazu zählen Mechanismen wie "Least-Privilege User Access", Codeintegritätsprüfungen und Privilege Isolation.

Benutzerkontensteuerung (UAC)

Windows-Benutzer neigen dazu, mit Administratorrechten zu arbeiten, da sie von vielen Anwendungen zur Installation und/oder zur Ausführung benötigt werden. Ein Beispiel ist die Notwendigkeit, standardmäßige Anwendungseinstellungen in die Registrierung schreiben zu können.

Das Arbeiten mit Administratorrechten bedeutet, dass Anwendungen von Prozessen ausgeführt werden, denen Administratorrechte gewährt werden. Für die Sicherheit bedeutet dies, dass jeder schädliche Code, der einen Prozess, der mit Administratorrechten ausgeführt wird, übernimmt, diese Berechtigungen automatisch vererbt. Dazu zählt der Zugriff auf wichtige Systemressourcen.

Eine Möglichkeit, sich vor diesem Sicherheitsrisiko zu schützen, ist die Ausführung von Anwendungen mit den geringsten Berechtigungen, die benötigt werden. Dieses Konzept wird als Prinzip der minimalen Berechtigungen bezeichnet und ist ein Hauptfeature des Betriebssystems Windows Vista. Dieses Feature nennt sich Benutzerkontensteuerung (User Account Control, UAC) und wird von der Windows Vista-UAC hauptsächlich auf zwei Arten eingesetzt:

• Um den Großteil der Anwendungen standardmäßig mit UAC-Berechtigungen auszuführen, selbst wenn der Benutzer Administrator ist. Nur Anwendungen, die Administratorrechte benötigen, werden auch mit Administratorrechten ausgeführt. Damit Anwendungen mit Administratorrechten ausgeführt werden, müssen sie im zugehörigen Anwendungsmanifest oder als Eintrag in den Sicherheitsrichtlinien explizit gekennzeichnet werden.

• Um Kompatibilitätslösungen wie Virtualisierung zur Verfügung zu stellen. Viele Anwendungen versuchen zum Beispiel, in beschränkte Speicherorte wie C:\Programme zu schreiben. Für Anwendungen, die unter UAC ausgeführt werden, ist ein alternativer Speicherort je Benutzer vorhanden, in den auch ohne Administratorrechte geschrieben werden darf. Für Anwendungen, die unter UAC ausgeführt werden, virtualisiert UAC den Pfad C:\Programme, sodass Anwendungen, die annehmen, in diesen Speicherort zu schreiben, dafür aber tatsächlich den alternativen Speicherort je Benutzer verwenden. Durch diese Art von Kompatibilitätsfunktion kann das Betriebssystem viele Anwendungen ausführen, die zuvor mit UAC nicht ausgeführt werden konnten.

Codeintegritätsprüfungen

Windows Vista enthält umfassendere Codeintegritätsprüfungen, um zu verhindern, dass zur Lade- bzw. Laufzeit schädlicher Code in Systemdateien oder den Kernel eingefügt wird. Dies geht über den Systemdateischutz hinaus.

Prozess mit eingeschränkten Rechten für im Browser gehostete Anwendungen

Im Browser gehostete WPF-Anwendungen werden in der Sandbox der Internetzone ausgeführt. Die WPF-Integration in Microsoft Internet Explorer erweitert diesen Schutz durch zusätzliche Unterstützung.

Internet Explorer 6 Service Pack 2 und Internet Explorer 7 für XP

WPF nutzt die Sicherheit des Betriebssystems durch die Begrenzung der Prozessberechtigungen für XAML browser applications (XBAPs) zum weiteren Schutz. Bevor eine im Browser gehostete WPF-Anwendung gestartet wird, erstellt das Betriebssystem einen Hostprozess, der unnötige Berechtigungen aus dem Prozesstoken entfernt. Zu den Berechtigungen, die entfernt werden, zählt etwa die Möglichkeit, den Computer des Benutzers herunterzufahren, Treiber zu laden und mit Leseberechtigung auf alle Dateien auf dem Computer zuzugreifen.

Internet Explorer 7 für Vista

In Windows Internet Explorer 7 werden WPF-Anwendungen im geschützten Modus ausgeführt. Insbesondere XAML browser applications (XBAPs) werden mit mittlerer Integrität ausgeführt.

Ebene mit umfassendem Schutz

Da für XAML browser applications (XBAPs) im Allgemeinen die Sandbox des Berechtigungssatzes für die Internetzone gilt, werden durch das Entfernen dieser Berechtigungen XAML browser applications (XBAPs) unter Kompatibilitätsaspekten nicht beeinträchtigt. Stattdessen wird eine zusätzliche Ebene mit umfassendem Schutz erstellt. Wenn eine Sandbox-Anwendung die Schwachstellen anderer Ebenen ausnutzen und den Prozess übernehmen kann, verfügt der Prozess weiterhin nur über eingeschränkte Berechtigungen.

Weitere Informationen finden Sie im Abschnitt zur Verwendung eines Benutzerkontos mit den geringsten Berechtigungen.

Sicherheit von Common Language Runtime

Die common language runtime (CLR) bietet eine Reihe von zentralen Sicherheitsvorteilen, darunter Validierung und Überprüfung, Code Access Security (CAS) und sicherheitsrelevante Methodik.

Validierung und Überprüfung

Um Isolation und Integrität von Assemblys bereitzustellen, verwendet die CLR einen Validierungsvorgang. Mit der CLR-Validierung wird sichergestellt, dass Assemblys isoliert werden, indem deren PE (Portable Executable)-Dateiformat auf Adressen überprüft wird, die auf Ziele außerhalb der Assembly zeigen. Die CLR-Validierung überprüft auch die Integrität der Metadaten, die in einer Assembly eingebettet sind.

Um die Typsicherheit zu gewährleisten, häufige Sicherheitsprobleme zu vermeiden (z. B. Pufferüberläufe) und die Sandboxfunktion durch die Isolation von Unterprozessen zu aktivieren, verwendet die CLR-Sicherheit das Konzept der Überprüfung.

Verwaltete Anwendungen werden in Microsoft Intermediate Language (MSIL) kompiliert. Wenn Methoden in einer verwalteten Anwendung ausgeführt werden, wird die zugehörige MSIL mithilfe der JIT (Just-In-Time)-Kompilierung in systemeigenen Code kompiliert. Die JIT-Kompilierung enthält einen Prüfungsvorgang, der viele Sicherheits- und Stabilitätsregeln anwendet, mit denen verhindert wird, dass Code:

• gegen Typverträge verstößt

• Pufferüberläufe erzeugt

• unkontrolliert auf den Arbeitsspeicher zugreift

Verwalteter Code, der den Überprüfungsregeln nicht entspricht, darf nur dann ausgeführt werden, wenn er als vertrauenswürdiger Code betrachtet wird.

Der Vorteil, den überprüfbarer Code bietet, ist ein Hauptgrund, warum WPF auf .NET Framework basiert. In dem Maße, wie überprüfbarer Code eingesetzt wird, sinkt die Gefahr, dass mögliche Schwachstellen ausgenutzt werden, erheblich.

Codezugriffssicherheit

Ein Clientcomputer macht eine große Anzahl an Ressourcen verfügbar, auf die eine verwaltete Anwendung zugreifen kann, einschließlich Dateisystem, Registrierung, Druckdienste, Benutzeroberfläche, Reflektion und Umgebungsvariablen. Bevor eine verwaltete Anwendung auf eine Ressource auf einem Clientcomputer zugreifen kann, muss sie dafür die .NET Framework-Code Access Security (CAS)-Berechtigung besitzen. Eine Berechtigung in CAS ist eine Unterklasse der CodeAccessPermission. CAS implementiert eine Unterklasse für jede Ressource, auf die verwaltete Anwendungen zugreifen können.

Der Satz von Berechtigungen, der von CAS für eine verwaltete Anwendung bei deren Start gewährt wird, wird als Berechtigungssatz bezeichnet und durch von der Anwendung bereitgestellte Beweise bestimmt. Für WPF-Anwendungen besteht der bereitgestellte Beweis aus dem Speicherort bzw. der Zone, von dem bzw. von der die Anwendungen gestartet werden. CAS identifiziert die folgenden Zonen:

• Arbeitsplatz. Anwendungen, die vom Clientcomputer aus gestartet werden (voll vertrauenswürdig).

• Lokales Intranet. Anwendungen, die vom Intranet aus gestartet werden. (Einigermaßen vertrauenswürdig).

• Internet. Anwendungen, die vom Internet aus gestartet werden. (Am wenigsten vertrauenswürdig).

• Vertrauenswürdige Sites. Anwendungen, die ein Benutzer als vertrauenswürdig betrachtet. (Am wenigsten vertrauenswürdig).

• Nicht vertrauenswürdige Sites. Anwendungen, die ein Benutzer als nicht vertrauenswürdig betrachtet. (Nicht vertrauenswürdig).

Für jede dieser Zonen stellt CAS einen vordefinierten Berechtigungssatz mit den Berechtigungen bereit, die der ihnen jeweils zugeordneten Vertrauensebene entsprechen. Dazu gehören:

• FullTrust. Für Anwendungen, die aus der Zone Arbeitsplatz gestartet werden. Alle möglichen Berechtigungen werden gewährt.

• LocalIntranet. Für Anwendungen, die aus der Zone Lokales Intranet gestartet werden. Es wird eine Teilmenge von Berechtigungen gewährt, um einen angemessenen Zugriff auf die Ressourcen eines Clientcomputers zu ermöglichen. Dazu zählen isolierte Speicherung, uneingeschränkter Zugriff auf die Benutzeroberfläche, uneingeschränkte Dateidialoge, eingeschränkte Reflektion, eingeschränkter Zugriff auf Umgebungsvariablen. Berechtigungen für wichtige Ressourcen wie die Registrierung werden nicht bereitgestellt.

• Internet. Für Anwendungen, die aus der Zone Internet oder Vertrauenswürdige Sites gestartet werden. Es wird eine Teilmenge von Berechtigungen gewährt, um einen eingeschränkten Zugriff auf die Ressourcen eines Clientcomputers zu ermöglichen. Dazu zählen isolierte Speicherung, Öffnen von Dateien und eingeschränkte Benutzeroberfläche. Im Wesentlichen werden mit diesem Berechtigungssatz Anwendungen vom Clientcomputer isoliert.

Ergibt die Identifikation von Anwendungen, dass sie aus der Zone Nicht vertrauenswürdige Sites stammen, werden ihnen von CAS überhaupt keine Berechtigungen gewährt. Infolgedessen gibt es für sie keinen vordefinierten Berechtigungssatz.

In der folgenden Abbildung wird die Beziehung zwischen Zonen, Berechtigungssätzen, Berechtigungen und Ressourcen dargestellt.

Die Einschränkungen der Sicherheitssandbox der Internetzone gilt für jeden Code, der von einer XBAP aus einer Systembibliothek importiert wird, einschließlich WPF. Dadurch wird sichergestellt, dass jedes Bit des Codes gesperrt wird, selbst WPF. Leider muss eine XBAP, um ausgeführt werden zu können, Funktionen ausführen, für die mehr Berechtigungen erforderlich sind, als durch die Sicherheitssandbox der Internetzone zugelassen werden.

Stellen Sie sich eine XBAP vor, die die folgende Seite enthält:

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Um diese XBAP auszuführen, muss der zugrunde liegende WPF-Code mehr Funktionen ausführen, als für die aufrufende XBAP zur Verfügung stehen. Dazu zählen:

• Erstellen eines Fensterhandles (hWnd) für das Rendern

• Weiterleiten von Meldungen

• Laden der Schriftart Tahoma

Unter Sicherheitsaspekten betrachtet, wäre es katastrophal, von der Sandbox-Anwendung aus einen direkten Zugriff auf einen dieser Vorgänge zu gestatten.

Zum Glück weist WPF einen Ausweg aus der Situation, indem diese Vorgänge für die Sandbox-Anwendung mit ausgeweiteten Berechtigungen ausgeführt werden können. Obwohl alle WPF-Vorgänge anhand der eingeschränkten Internetzonen-Sicherheitsberechtigungen der Anwendungsdomäne von XBAP überprüft werden, erhält WPF (wie auch andere Systembibliotheken) einen Berechtigungssatz, der alle möglichen Berechtigungen enthält.

WPF muss daher ausgeweitete Berechtigungen erhalten, gleichzeitig aber dafür sorgen, dass diese Berechtigungen nicht vom Internetzonen-Berechtigungssatz der Hostanwendungsdomäne verwaltet werden.

Hierzu verwendet WPF die Assert-Methode einer Berechtigung. Dies wird im folgenden Code veranschaulicht.

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Im Grunde verhindert Assert, dass die von WPF benötigten uneingeschränkten Berechtigungen durch die Internetzonen-Berechtigungen der XBAP eingeschränkt werden.

Von der Plattform aus betrachtet, ist WPF für die ordnungsgemäße Verwendung von Assert verantwortlich. Eine falsche Verwendung von Assert kann dazu führen, dass schädlicher Code seine Berechtigungen ausweitet. Daher ist es wichtig, Assert nur bei Bedarf aufzurufen und sicherzustellen, dass Sandbox-Einschränkungen unverändert bleiben. Sandbox-Code darf z. B. nicht beliebige Dateien öffnen, darf aber Schriftarten verwenden. WPF ermöglicht es Sandbox-Anwendungen, durch Aufrufen von Assert Schriftartfunktionen zu nutzen. WPF darf für die Sandbox-Anwendung Dateien lesen, die diese Schriftarten enthalten.

ClickOnce-Bereitstellung

ClickOnce ist eine umfangreiche Bereitstellungstechnologie, die in .NET Framework enthalten und in Microsoft Visual Studio integriert ist (weitere Informationen finden Sie unter Übersicht über die ClickOnce-Bereitstellung). Eigenständige WPF-Anwendungen können mit ClickOnce bereitgestellt werden, während im Browser gehostete Anwendungen mit ClickOnce bereitgestellt werden müssen.

Mit ClickOnce bereitgestellte Anwendungen erhalten eine zusätzliche Sicherheitsebene mithilfe von Code Access Security (CAS). Im Prinzip fordern mit ClickOnce bereitgestellte Anwendungen die Berechtigungen an, die sie benötigen. Sie erhalten diese Berechtigungen nur dann, wenn diese den Berechtigungssatz für die Zone, aus der die Anwendung bereitgestellt wird, nicht überschreiten. Durch Reduzierung des Berechtigungssatzes auf lediglich die tatsächlich benötigten Berechtigungen, selbst wenn sie weniger umfangreich sind als die, die vom Berechtigungssatz der Startzone bereitgestellt werden, wird die Anzahl der Ressourcen, auf die die Anwendung zugreifen kann, auf ein absolutes Minimum beschränkt. Wenn die Anwendung übernommen wird, ist deshalb der mögliche Schaden für den Clientcomputer begrenzt.

Sicherheitsrelevante Methodik

Für den WPF-Code, der mithilfe von Berechtigungen die Sandbox der Internetzone für XBAP-Anwendungen aktiviert, muss der höchstmögliche Grad der Sicherheitsüberprüfung und -kontrolle gelten. Damit diese Anforderung einfach umgesetzt werden kann, bietet .NET Framework neue Unterstützung zur Verwaltung von Code, der seine Berechtigungen ausweitet. Insbesondere mit CLR können Sie Code, der seine Berechtigungen ausweitet, erkennen und ihn mit dem SecurityCriticalAttribute kennzeichnen. Jeder nicht mit SecurityCriticalAttribute gekennzeichnete Code wird mithilfe dieser Methodik transparent. Umgekehrt wird verhindert, dass nicht mit SecurityCriticalAttribute gekennzeichneter verwalteter Code seine Berechtigungen ausweitet.

Mit der sicherheitsrelevanten Methodik kann WPF-Code, der seine Berechtigungen ausweitet, im sicherheitsrelevanten Kernel abgelegt werden, wobei der Rest transparent dargestellt wird. Durch Isolieren des sicherheitsrelevanten Codes kann das WPF-Entwicklungsteam sich auf eine zusätzliche Sicherheitsanalyse und Quellcodeverwaltung für den sicherheitsrelevanten Kernel jenseits von Standardsicherheitsmaßnahmen konzentrieren (siehe WPF-Sicherheitsstrategie – Sicherheitsentwicklung).

Beachten Sie, dass in .NET Framework vertrauenswürdiger Code die XBAP-Sandbox der Internetzone erweitern kann, da Entwickler verwaltete Assemblys schreiben können, die mit AllowPartiallyTrustedCallersAttribute (APTCA) gekennzeichnet und für den globalen Assemblycache (GAC) des Benutzers bereitgestellt werden. Das Kennzeichnen einer Assembly mit APTCA ist ein extrem kritischer Sicherheitsvorgang, da hierdurch jeder Code diese Assembly aufrufen kann, einschließlich schädlichen Codes aus dem Internet. Bei diesem Vorgang müssen äußerste Vorsicht und bewährte Methoden eingehalten werden. Außerdem müssen Benutzer diese Software als vertrauenswürdig einstufen, damit sie installiert werden kann.

Sicherheit von Microsoft Internet Explorer

Mit Microsoft Internet Explorer 6 (SP2) werden nicht nur Sicherheitsprobleme reduziert und die Sicherheitskonfiguration vereinfacht, es sind auch etliche Features enthalten, die für Benutzer von XAML browser applications (XBAPs) die Sicherheit erhöhen. Mit diesen Features sollen Benutzer eine größere Kontrolle über das Browserverhalten erhalten.

Vor IE6 SP2 konnten Benutzer durch Folgendes belästigt werden:

• Zufällige Popupfenster.

• Verwirrende Skriptumleitung.

• Zahlreiche Sicherheitsdialogfelder auf einigen Websites.

In einigen Fällen versuchten nicht vertrauenswürdige Websites Benutzer mit einer vorgetäuschten Installations-user interface (UI) oder einem wiederholt angezeigten Microsoft ActiveX-Installationsdialogfeld in die Irre zu führen, obwohl der Benutzer den Vorgang abgebrochen hat. Durch Einsatz dieser Techniken ist es möglich, dass eine beträchtliche Zahl an Benutzern zu fragwürdigen Entscheidungen verleitet wurde, die zur Installation von Spyware-Anwendungen führten.

IE6 SP2 enthält mehrere Features, um diese Art von Problemen zu verringern, denen mit dem Konzept der Aktivierung durch den Benutzer begegnet wird. IE6 SP2 erkennt, ob ein Benutzer auf einen Link oder ein Seitenelement geklickt hat, bevor eine Aktion ausgeführt wird. Dies wird als Aktivierung durch den Benutzer bezeichnet und anders behandelt, als wenn eine vergleichbare Aktion von dem Skript auf einer Seite ausgelöst wird. IE6 SP2 enthält zum Beispiel einen Popupblocker, der erkennt, ob ein Benutzer auf eine Schaltfläche klickt, bevor die Seite ein Popupelement erstellt. Somit kann IE6 SP2 die meisten harmlosen Popupelemente zulassen und diejenigen unterdrücken, die Benutzer weder anfordern noch wünschen. Blockierte Popupelemente werden unter der neuen Informationsleiste aufgefangen, mit der der Benutzer die Sperre manuell deaktivieren und das Popupelement anzeigen kann.

Dieselbe Logik der Aktivierung durch den Benutzer wird auch auf die Sicherheitshinweise Öffnen/Speichern angewendet. ActiveX-Installationsdialogfelder werden immer unter der Informationsleiste aufgefangen, es sei denn, es handelt sich bei ihnen um das Upgrade eines bereits installierten Steuerelements. All diese Maßnahmen tragen zu mehr Sicherheit und Kontrolle im Rahmen der Benutzererfahrung bei, denn die Benutzer werden vor Websites geschützt, die sie mit der Installation unerwünschter bzw. schädlicher Software belästigen.

Durch diese Features werden auch Kunden geschützt, die mit IE6 SP2 Websites besuchen, von denen sie WPF-Anwendungen herunterladen und installieren können. Dies gilt insbesondere deshalb, da IE6 SP2 mehr Benutzererfahrung bietet, die die Möglichkeit einschränkt, dass Benutzer schädliche oder den eigentlichen Zweck verschleiernde Anwendungen installieren, unabhängig mit welcher Technologie sie erstellt wurden, einschließlich WPF. WPF trägt zu diesen Schutzvorkehrungen durch die Verwendung von ClickOnce bei, um das Herunterladen der zugehörigen Anwendungen über das Internet zu vereinfachen. Da XAML browser applications (XBAPs) innerhalb einer Sicherheitssandbox der Internetzone ausgeführt werden, können sie problemlos gestartet werden. Andererseits benötigen eigenständige WPF-Anwendungen die volle Vertrauenswürdigkeit, um ausgeführt zu werden. Für diese Anwendungen wird in ClickOnce während des Startvorgangs ein Sicherheitsdialogfeld angezeigt, das über die Verwendung der zusätzlichen Sicherheitsanforderungen der Anwendung informiert. Dieser Schutz muss allerdings durch den Benutzer initiiert werden, unterliegt auch der Logik der Aktivierung durch den Benutzer und kann abgebrochen werden.

Internet Explorer 7 enthält und erweitert die Sicherheitsfunktionen von IE6 SP2 als Teil des stetigen Engagements für Sicherheit.

Siehe auch

Konzepte

Codezugriffssicherheit

Sicherheit (WPF)

WPF-Sicherheit mit teilweiser Vertrauenswürdigkeit

WPF-Sicherheitsstrategie – Sicherheitsentwicklung

Weitere Ressourcen

Grundlegendes zur Sicherheit in Microsoft Internet Explorer 6 in Windows XP SP2

Grundlegendes zum geschützten Modus von Internet Explorer und dessen Verwendung

Windows XP Service Pack 3

Sicherheitsleitfaden für Windows Vista