WPF-Sicherheitsstrategie – Plattformsicherheit

Windows Presentation Foundation (WPF) stellt nicht nur eine Vielzahl von Sicherheitsdiensten bereit, sondern nutzt auch die Sicherheitsfeatures der zugrundeliegenden Plattform, wozu das Betriebssystem, die CLR und Internet Explorer gehören. Im Zusammenspiel stellen diese Ebenen für WPF ein leistungsfähiges Modell für tiefgreifende, vorbeugende Sicherheitsmaßnahmen (Defense-in-Depth-Modell) bereit, das eine einzelne Fehlerquelle zu vermeiden sucht, wie aus der folgenden Abbildung hervorgeht:

Im weiteren Verlauf dieses Themas werden die Features auf den einzelnen Ebenen erläutert, die besonders WPF betreffen.

Sicherheit des Betriebssystems

Der Kern von Windows enthält verschiedene Sicherheitsfeatures, die die Sicherheitsgrundlage für alle Windows-Anwendungen bilden, auch für die mit WPF erstellten Anwendungen. In diesem Thema wird der Umfang dieser Sicherheitsfeatures behandelt, die für WPF wichtig sind. Erläutert wird auch die Integration mit WPF, um weitere tiefgreifende Vorbeugungsmaßnahmen bereitzustellen.

Microsoft Windows XP Service Pack 2 (SP2)

Neben einer allgemeinen Überprüfung und Stärkung von Windows gibt es drei wichtige Funktionen von Windows XP SP2, die in diesem Thema behandelt werden:

• /GS-Kompilierung

• Microsoft Windows Update.

/GS-Kompilierung

Windows XP SP2 bietet Schutz durch das erneute Kompilieren vieler zentraler Systembibliotheken, einschließlich aller WPF-Abhängigkeiten wie die CLR, um das Risiko von Pufferüberläufen zu verringern. Dies wird mit dem /GS-Parameter und dem C/C++-Befehlszeilencompiler erreicht. Obwohl Pufferüberläufe ausdrücklich vermieden werden sollten, ist die Kompilierung mit /GS ein Beispiel für eine tiefgreifende Verteidigungsmaßnahme gegen potenzielle Sicherheitslücken, die versehentlich oder böswillig durch Pufferüberläufe erzeugt werden.

In der Vergangenheit waren Pufferüberläufe die Ursache für viele Sicherheitslücken mit gravierenden Folgen. Ein Pufferüberlauf tritt auf, wenn ein Angreifer die Sicherheitsanfälligkeit eines Codes nutzt, die das Einfügen von schädlichem Code ermöglicht, der über die Begrenzungen eines Puffers schreibt. Ein Angreifer kann dann durch Überschreiben der Rückgabeadresse einer Funktion den Prozess, in dem der Code ausgeführt wird, hacken und die Ausführung des Angreifercodes auslösen. Daraus entsteht bösartiger Code, der beliebigen Code mit den gleichen Berechtigungen wie der gehackte Prozess ausführt.

Auf hoher Ebene schützt das -GS-Compilerflag vor einigen möglichen Pufferüberläufen, indem es zum Schutz der Rückgabeadresse einer Funktion, die über lokale Zeichenfolgepuffer verfügt, ein spezielles Sicherheitscookie einschleust. Nach der Rückgabe einer Funktion wird das Sicherheitscookie mit seinem vorherigen Wert verglichen. Hat sich der Wert geändert, ist möglicherweise ein Pufferüberlauf aufgetreten, und der Prozess wird mit einer Fehlerbedingung beendet. Das Beenden des Prozesses verhindert die Ausführung von potenziell bösartigem Code. Ausführlichere Informationen finden Sie unter -GS (Puffersicherheitsüberprüfung).

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

Windows Vista

WPF-Benutzer mit Windows Vista profitieren von zusätzlichen Verbesserungen des Betriebssystems in puncto Sicherheit, z. B. Benutzerkontensteuerung, Integritätsprüfungen für Code und Rechteisolierung.

Benutzerkontensteuerung (User Account Control, UAC)

Derzeit neigen Benutzer von Windows dazu, mit Administratorrechten zu arbeiten, da diese für viele Anwendungen (entweder für die Installation und/oder die Ausführung) erforderlich sind. Das Schreiben von Standardanwendungseinstellungen in die Registrierung ist nur ein Beispiel.

Das Arbeiten mit Administratorrechten bedeutet im Grunde, dass Anwendungen von Prozessen ausgeführt werden, denen Administratorrechte gewährt werden. Das hat Auswirkungen auf die Sicherheit, denn bösartiger Code, der zum Hacken eines mit Administratorrechten ausgeführten Prozesses verwendet wird, übernimmt automatisch dessen Berechtigungen, einschließlich des Zugriffs auf kritische Systemressourcen.

Anwendungen nur mit den unbedingt erforderlichen Berechtigungen auszuführen, ist eine Möglichkeit, sich vor dieser Sicherheitsbedrohung zu schützen. Dieses sogenannte „Prinzip der geringsten Rechte“ ist ein zentrales Feature des Betriebssystems Windows. Diese als Benutzerkontensteuerung bezeichnete Funktion wird von Windows auf zweierlei Weise verwendet:

• Die meisten Anwendungen werden standardmäßig mit den Rechten der Benutzerkontensteuerung ausgeführt, selbst wenn der Benutzer ein Administrator ist; nur Anwendungen, die Administratorrechte benötigen, werden mit Administratorrechten ausgeführt. Um mit Administratorrechten ausgeführt zu werden, müssen Anwendungen entweder in ihrem Anwendungsmanifest oder als Eintrag in der Sicherheitsrichtlinie besonders gekennzeichnet werden.

• Bereitstellen von Kompatibilitätslösungen wie die Virtualisierung. Viele Anwendungen versuchen beipielsweise, in eingeschränkte Speicherorte wie "C:\Programme" zu schreiben. Für Anwendungen, die über die Benutzerkontensteuerung ausgeführt werden, steht ein alternativer benutzerbezogener Speicherort zur Verfügung, der für Schreibvorgänge keine Administratorrechte erfordert. Für Anwendungen, die über die Benutzerkontensteuerung ausgeführt werden, wird "C:\Programme" virtualisiert. Dadurch wird der Anschein erweckt, dass die Anwendungen in dieses Verzeichnis schreiben, obwohl sie stattdessen in den alternativen, benutzerbezogenen Speicherort schreiben. Dank dieser Art von Kompatibilität kann das Betriebssystem viele Anwendungen ausführen, die zuvor nicht mit der Benutzerkontensteuerung ausgeführt werden konnten.

Integritätsprüfungen für Code

Windows Vista enthält strengere Integritätsprüfungen für Code, um zu verhindern, dass bösartiger Code zur Lade-/Laufzeit in Systemdateien oder den Kernel eingeschleust wird. Dies geht über den Schutz der Systemdateien hinaus.

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

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

Warnung

XBAPs erfordern Legacybrowser, z. B. Internet Explorer und ältere Versionen von Firefox. Diese älteren Browser werden unter Windows 10 und Windows 11 normalerweise nicht unterstützt. Moderne Browser unterstützen die für XBAP-Apps erforderliche Technologie aufgrund von Sicherheitsrisiken nicht mehr. Plug-Ins, die XBAPs aktivieren, werden nicht mehr unterstützt. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu von browsergehosteten WPF-Anwendungen (XBAP).

Da XAML-Browseranwendungen (XBAPs) im Allgemeinen durch den Berechtigungssatz für die Internetzone in einer Sandbox ausgeführt werden, beeinträchtigt das Entfernen dieser Berechtigungen XAML-Browseranwendungen (XBAPs) aus Kompatibilitätsperspektive nicht. Stattdessen wird eine zusätzliche Defense-in-Depth-Ebene geschaffen. Wenn eine in einem Sicherheitssandkasten ausgeführte Anwendung in der Lage ist, andere Ebenen anzugreifen und den Prozess zu hacken, verfügt auch der Prozess nur über eingeschränkte Berechtigungen.

Weitere Informationen finden Sie unter Verwenden eines Benutzerkontos mit den geringsten Berechtigungen.

Common Language Runtime-Sicherheit

Die Common Language Runtime (CLR) bietet eine Reihe wichtiger Vorteile in puncto Sicherheit. Dazu zählen Validierung und Überprüfung, Codezugriffssicherheit (CAS) sowie die sicherheitsrelevante Methode.

Validierung und Prüfung

Assemblyisolation und Integrität wird von der CLR über einen Validierungsprozess bereitgestellt. Mit der CLR-Validierung wird sichergestellt, dass Assemblys isoliert werden. Dazu wird deren PE-Dateiformat (Portable Executable) für Adressen validiert, die auf eine Stelle außerhalb der Assembly verweisen. Die CLR-Validierung validiert auch die Integrität der in eine Assembly eingebetteten Metadaten.

Um die Typsicherheit zu gewährleisten, häufige Sicherheitsprobleme (z. B. Pufferüberläufe) zu vermeiden und durch die Isolation von Unterprozessen die Ausführung in einem Sicherheitssandkasten zu ermöglichen, setzt die CLR-Sicherheit das Prüfprinzip ein.

Verwaltete Anwendungen werden in Microsoft Intermediate Language (MSIL) kompiliert. Wenn Methoden in einer verwalteten Anwendung ausgeführt werden, wird die MSIL über Just-in-Time (JIT)-Kompilierung in systemeigenen Code kompiliert. Die JIT-Kompilierung enthält einen Prüfprozess mit vielen Sicherheits- und Stabilitätsregeln, die sicherstellen, dass der Code keine der folgenden Eigenschaften aufweist:

• Verletzen von Typverträgen

• Verursachen von Pufferüberläufen

• Unkontrollierter Zugriff auf den Arbeitsspeicher

Verwalteter Code, der den Prüfregeln nicht entspricht, darf nur dann ausgeführt werden, wenn er als vertrauenswürdiger Code gilt.

Der Vorteil des prüfbaren Codes ist einer der wichtigsten Gründe, warum WPF auf .NET Framework aufbaut. Mit zunehmender Verwendung prüfbaren Codes sinkt die Wahrscheinlichkeit, dass potenzielle Schwachstellen ausgenutzt werden, ganz erheblich.

Codezugriffssicherheit

Ein Clientcomputer stellt eine Vielzahl von Ressourcen bereit, auf die eine verwaltete Anwendung zugreifen kann. Dazu zählen u. a. Dateisystem, Registrierung, Druckdienste, Benutzeroberfläche, Reflektion und Umgebungsvariablen. Bevor eine verwaltete Anwendung auf eine Ressource auf einem Clientcomputer zugreifen kann, benötigt sie dafür die .NET Framework-Berechtigung. Eine Berechtigung in CAS ist eine Unterklasse von CodeAccessPermission. CAS implementiert eine Unterklasse für jede Ressource, auf die verwaltete Anwendungen zugreifen können.

Der Satz von Rechten, den CAS einer verwalteten Anwendung beim Starten gewährt, wird als Berechtigungssatz bezeichnet. Er richtet sich nach den von der Anwendung bereitgestellten Nachweisen. Bei WPF-Anwendungen wird als Nachweis der Speicherort oder die Zone bereitgestellt, von dem bzw. der die Anwendungen gestartet werden. CAS identifiziert die folgenden Zonen:

• Arbeitsplatz. Anwendungen, die auf dem Clientcomputer gestartet werden (voll vertrauenswürdig).

• Lokales Intranet. Anwendungen, die aus dem Intranet gestartet werden (in gewisser Weise vertrauenswürdig).

• Internet. Anwendungen, die aus dem Internet gestartet werden (wenig vertrauenswürdig).

• Vertrauenswürdige Sites. Anwendungen, die von einem Benutzer als vertrauenswürdig identifiziert wurden (wenig vertrauenswürdig).

• Nicht vertrauenswürdige Sites. Anwendungen, die von einem Benutzer als nicht vertrauenswürdig identifiziert wurden (nicht vertrauenswürdig).

Für jede dieser Zonen stellt CAS einen vordefinierten Berechtigungssatz bereit, der die Berechtigungen enthält, die der jeweils zugeordneten Vertrauensebene entsprechen. Dazu zählen unter anderem folgende Einstellungen:

• 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. Für einen moderaten Zugriff auf die Ressourcen des Clientcomputers wird eine Teilmenge von Berechtigungen gewährt. Dazu zählen isolierter Speicher, uneingeschränkter Zugriff auf die Benutzeroberfläche und Dateidialogfelder, eingeschränkte Reflektion sowie eingeschränkter Zugriff auf Umgebungsvariablen. Berechtigungen für kritische Ressourcen wie die Registrierung werden nicht bereitgestellt.

• Internet. Für Anwendungen, die aus der Zone Internet oder Vertrauenswürdige Sites gestartet werden. Für einen eingeschränkten Zugriff auf die Ressourcen des Clientcomputers wird eine Teilmenge von Berechtigungen gewährt. Dazu zählen isolierter Speicher, Öffnen von Dateien sowie eingeschränkter Zugriff auf die Benutzeroberfläche. Im Grunde isolieren diese Berechtigungssätze die Anwendungen vom Clientcomputer.

Anwendungen, die aus der Zone Nicht vertrauenswürdige Sites stammen, gewährt CAS überhaupt keine Berechtigungen. Daher gibt es für diese Anwendungen keinen vordefinierten Berechtigungssatz.

Die folgende Abbildung veranschaulicht die Beziehung zwischen Zonen, Berechtigungssätzen, Berechtigungen und Ressourcen:

Die Einschränkungen der Sicherheitssandbox der Internetzone gelten in gleicher Weise für jeden Code, den eine XBAP aus einer Systembibliothek importiert (einschließlich WPF). Dadurch wird sichergestellt, dass jedes Bit des Codes (selbst WPF) gesperrt wird. Unglücklicherweise muss eine XBAP jedoch, um ausgeführt zu werden, Funktionalität ausführen, die mehr Berechtigungen erfordert, als im Rahmen der Sicherheitssandbox der Internetzone gewährt werden.

Warnung

XBAPs erfordern Legacybrowser, z. B. Internet Explorer und ältere Versionen von Firefox. Diese älteren Browser werden unter Windows 10 und Windows 11 normalerweise nicht unterstützt. Moderne Browser unterstützen die für XBAP-Apps erforderliche Technologie aufgrund von Sicherheitsrisiken nicht mehr. Plug-Ins, die XBAPs aktivieren, werden nicht mehr unterstützt. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu von browsergehosteten WPF-Anwendungen (XBAP).

Nehmen Sie beispielsweise eine XBAP-Anwendung, die die folgende Seite enthält:

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

// Perform operation that uses the assert

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

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

' Perform operation that uses the assert

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

Zum Ausführen dieser XBAP muss der zugrunde liegende WPF-Code mehr Funktionalität ausführen, als der aufrufenden XBAP zur Verfügung steht. Dazu zählen:

• Erstellen eines Fensterhandles (HWND) für das Rendering

• Verteilen von Nachrichten

• Laden der Schriftart Tahoma

Unter dem Gesichtspunkt der Sicherheit wäre die Gewährung des direkten Zugriffs auf diese Vorgänge für die im Sicherheitssandkasten ausgeführte Anwendung eine Katastrophe.

Zum Glück bietet WPF einen Ausweg aus dieser Lage, indem diesen Vorgängen die Ausführung mit erhöhten Rechten im Namen der in der Sicherheitssandbox ausgeführten Anwendung erlaubt wird. Während alle WPF-Vorgänge anhand der eingeschränkten Sicherheitsberechtigungen der Internetzone der XBAP-Anwendungsdomäne überprüft werden, wird WPF (wie anderen Systembibliotheken) ein Berechtigungssatz gewährt, der alle möglichen Berechtigungen enthält.

Dies setzt voraus, dass WPF erhöhte Rechte eingeräumt werden und gleichzeitig verhindert wird, dass diese Berechtigungen vom Berechtigungssatz der Internetzone der Hostanwendungsdomäne gesteuert werden.

WPF verwendet dazu für eine Berechtigung die Assert-Methode. Der folgende Code beschreibt die Vorgehensweise.

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

// Perform operation that uses the assert

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

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

' Perform operation that uses the assert

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

Mit Assert wird im Grunde verhindert, dass die für WPF erforderlichen uneingeschränkten Berechtigungen durch die Berechtigungen der Internetzone der XBAP eingeschränkt werden.

Aus Plattformsicht ist WPF für die richtige Anwendung von Assert verantwortlich; eine falsche Verwendung von Assert könnte schädlichem Code die Möglichkeit geben, die Rechte zu erhöhen. Daher ist es wichtig, Assert nur bei Bedarf aufzurufen und dabei sicherzustellen, dass die Einschränkungen der Sicherheitssandbox unverändert erhalten bleiben. Beispielsweise darf im Sicherheitssandkasten ausgeführter Code zwar keine beliebigen Dateien öffnen, aber Schriftarten verwenden. WPF bietet durch den Aufruf von Assert den in der Sicherheitssandbox ausgeführten Anwendungen die Möglichkeit, die Schriftartfunktion zu verwenden, und WPF liest dann im Namen dieser Anwendung in der Sandbox die Dateien, die bekanntermaßen diese Schriftarten enthalten.

ClickOnce-Bereitstellung

ClickOnce ist eine umfassende Bereitstellungstechnologie, die in .NET Framework enthalten ist und sich in Visual Studio integrieren lässt (detaillierte Informationen finden Sie unter ClickOnce-Sicherheit und -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 werden durch Codezugriffssicherheit (CAS) mit einer weiteren Sicherheitsebene ausgestattet; im Grunde fordern mit ClickOnce bereitgestellte Anwendungen nur die von ihnen benötigten Berechtigungen an. Diese Berechtigungen werden nur gewährt, wenn sie nicht höher sind als die Berechtigungen im Berechtigungssatz für die Zone, von der die Anwendung bereitgestellt wird. Durch die Reduzierung des Berechtigungssatzes auf die benötigten Berechtigungen (selbst wenn diese niedriger sind als die Berechtigungen im Berechtigungssatz der Startzone) wird die Anzahl der Ressourcen, auf welche die Anwendung zugreifen kann, auf ein absolutes Minimum reduziert. Dadurch wird der mögliche Schaden für den Clientcomputer reduziert, falls die Anwendung gehackt wird.

Sicherheitsrelevante Methode

Für den WPF-Code, der mithilfe von Berechtigungen die Sicherheitssandbox der Internetzone für XBAP-Anwendungen aktiviert, muss stets das höchstmögliche Maß an Sicherheitsüberwachung und -kontrolle gelten. Um diese Anforderung zu erleichtern, stellt .NET Framework neue Unterstützung für die Verwaltung von Code bereit, der Rechte erhöht. Insbesondere die CLR ermöglicht es Ihnen, Code zu identifizieren, der Rechte erhöht, und diesen mit SecurityCriticalAttribute zu kennzeichnen. Nicht mit SecurityCriticalAttribute gekennzeichneter Code wird mit dieser Methode transparent. Umgekehrt wird verhindert, dass verwalteter Code, der nicht mit dem SecurityCriticalAttribute gekennzeichnet ist, die Rechte erhöht.

Warnung

XBAPs erfordern Legacybrowser, z. B. Internet Explorer und ältere Versionen von Firefox. Diese älteren Browser werden unter Windows 10 und Windows 11 normalerweise nicht unterstützt. Moderne Browser unterstützen die für XBAP-Apps erforderliche Technologie aufgrund von Sicherheitsrisiken nicht mehr. Plug-Ins, die XBAPs aktivieren, werden nicht mehr unterstützt. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu von browsergehosteten WPF-Anwendungen (XBAP).

Die sicherheitsrelevante Methode ermöglicht die Organisation von WPF-Code, der Rechte bis in den sicherheitskritischen Kernel erhöht, während der Rest transparent dargestellt wird. Durch das Isolieren des sicherheitskritischen Codes kann sich das WPF-Entwicklungsteam auf eine zusätzliche Sicherheitsanalyse und Quellcodekontrolle für den sicherheitskritischen Kernel konzentrieren, die weit über die Standardsicherheitsmaßnahmen hinausgehen (weitere Informationen finden Sie unter WPF-Sicherheitsstrategie – Sicherheitsentwicklung).

Beachten Sie, dass .NET Framework vertrauenswürdigem Code erlaubt, die Sicherheitssandbox der Internetzone für die XBAP zu erweitern, indem es Entwicklern gestattet wird, verwaltete Assemblys zu schreiben, die mit AllowPartiallyTrustedCallersAttribute (APTCA) gekennzeichnet und im globalen Assemblycache (GAC) des Benutzers bereitgestellt werden. Das Kennzeichnen einer Assembly mit dem APTCA-Attribut ist ein extrem kritischer Sicherheitsvorgang, da jeder Code, auch bösartiger Code aus dem Internet, diese Assembly aufrufen kann. Bei diesem Vorgang sind äußerste Vorsicht und die Verwendung bewährter Methoden ein absolutes Muss. Die Benutzer müssen zuerst angeben, dass sie dieser Software vertrauen, bevor sie installiert werden kann.

Microsoft Internet Explorer-Sicherheit

Neben Funktionen zum Reduzieren von Sicherheitsproblemen und zum Vereinfachen der Sicherheitskonfiguration enthält Microsoft Internet Explorer 6 (SP2) verschiedene Features, die die Sicherheit für die Benutzer von XAML-Browseranwendungen (XBAPs) noch weiter erhöhen. Hauptziel dieser Features ist eine bessere Kontrolle des Benutzers über seine Arbeit im Brower.

Warnung

XBAPs erfordern Legacybrowser, z. B. Internet Explorer und ältere Versionen von Firefox. Diese älteren Browser werden unter Windows 10 und Windows 11 normalerweise nicht unterstützt. Moderne Browser unterstützen die für XBAP-Apps erforderliche Technologie aufgrund von Sicherheitsrisiken nicht mehr. Plug-Ins, die XBAPs aktivieren, werden nicht mehr unterstützt. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu von browsergehosteten WPF-Anwendungen (XBAP).

Vor IE6 SP2 mussten Benutzer mit Folgendem rechnen:

• Zufällige Popupfenster

• Verwirrende Skriptumleitung

• Zahlreiche Sicherheitsdialogfelder auf manchen Websites

In einigen Fällen versuchten nicht vertrauenswürdige Websites, Benutzer durch Spoofing der Installationsbenutzeroberfläche (UI) oder wiederholtes Anzeigen eines Microsoft ActiveX-Installationsdialogfelds zu täuschen, obwohl der Benutzer den Vorgang bereits abgebrochen hatte. Mit diesen Techniken ist es möglich, eine große Anzahl von Benutzern zu schlechten Entscheidungen zu verleiten, die zur Installation von Spyware-Anwendungen führen.

IE6 SP2 enthält mehrere Features, um diese Art von Problemen rund um das Prinzip der Benutzerinitiierung zu minimieren. IE6 SP2 erkennt, wenn ein Benutzer vor einer Aktion auf einen Link oder ein Seitenelement geklickt hat (als Benutzerinitiierung bezeichnet), und behandelt den Vorgang anders als eine ähnliche Aktion, die von dem Skript auf der Seite ausgeführt wird. Beispielsweise enthält IE6 SP2 einen Popupblocker, der erkennt, wenn ein Benutzer auf eine Schaltfläche klickt, bevor auf der Seite ein Popup erstellt wird. Auf diese Weise kann IE6 SP2 die meisten unschädlichen Popups zulassen und gleichzeitig die Popups verhindern, die Benutzer weder anfordern noch wünschen. Blockierte Popups werden unter der neuen Informationsleiste erfasst. Dadurch kann der Benutzer die Blockierung überschreiben und das Popup anzeigen.

Die Benutzerinitiierungslogik gilt auch für die Sicherheitshinweise beim Öffnen/Speichern. ActiveX-Installationsdialogfelder werden immer unter der Informationsleiste erfasst, sofern es sich nicht um das Upgrade eines bereits installierten Steuerelements handelt. All diese Maßnahmen sorgen für eine Benutzererfahrung mit mehr Sicherheit und Kontrolle und bieten Schutz vor Websites, die den Benutzer belästigen und zur Installation von unerwünschter oder schädlicher Software verleiten wollen.

Diese Funktionen schützen auch die Kunden, die mit IE6 SP2 zu Websites navigieren, auf denen sie WPF-Anwendungen herunterladen und installieren können. Hauptgrund dafür ist die bessere Benutzererfahrung, die IE6 SP2 ermöglicht und die weniger Gelegenheit zum Installieren schädlicher oder undurchsichtiger Anwendungen bietet, und zwar ungeachtet der zum Erstellen verwendeten Technologie (einschließlich WPF). WPF erweitert durch die Verwendung von ClickOnce diese Schutzmaßnahmen noch und vereinfacht damit das Herunterladen der zugehörigen Anwendungen über das Internet. Da XAML-Browseranwendungen (XBAPs) innerhalb einer Sicherheitssandbox der Internetzone ausgeführt werden, können sie nahtlos gestartet werden. Andererseits setzen eigenständige WPF-Anwendungen vollständige Vertrauenswürdigkeit voraus, um ausgeführt werden zu können. Für diese Anwendungen zeigt ClickOnce beim Startvorgang ein Sicherheitsdialogfeld an, um auf die Verwendung der zusätzlichen Sicherheitsanforderungen der Anwendung hinzuweisen. Da dies vom Benutzer initiiert werden muss, unterliegt der Vorgang außerdem der Benutzerinitiierungslogik und kann kann abgebrochen werden.

Im Rahmen unseres stetigen Engagements für die Sicherheit enthält Internet Explorer 7 die Sicherheitsfunktionen von IE6 SP2 und erweitert diese noch.

Siehe auch

• Codezugriffssicherheit
• Security
• WPF-Sicherheit mit teilweiser Vertrauenswürdigkeit
• WPF-Sicherheitsstrategie – Sicherheitsentwicklung