Freigeben über

Überlegungen zur Sicherheit von Office-Projektmappen

  • Artikel

Die von Microsoft .NET Framework und Microsoft Office bereitgestellten Sicherheitsfeatures können in Office-Projektmappen zum Schutz vor möglichen Sicherheitsbedrohungen beitragen. In diesem Thema werden einige dieser Bedrohungen erläutert und Empfehlungen bereitgestellt, wie sich vor diesen Bedrohungen schützen lässt. Es beinhaltet auch Informationen dazu, wie sich Microsoft Office-Sicherheitseinstellungen auf Office-Projektmappen auswirken.

Gilt für: Die Informationen in diesem Thema gelten für Projekte auf Dokumentebene und VSTO-Add-In-Projekte. Siehe Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Vertrauenswürdiger Code wird in einem neuen, schädlichen Dokument für einen anderen Zweck ausgenutzt

Ein Angreifer könnte vertrauenswürdigen Code, der für einen bestimmten Zweck vorgesehen ist, etwa Herunterladen persönlicher Daten für eine Bewerbung, übernehmen und in einem anderen Dokument, z. B. einem Arbeitsblatt, erneut verwenden. Der Code weiß nicht, dass nicht das Originaldokument ausgeführt wird, und begünstigt möglicherweise andere Bedrohungen, etwa Offenlegung persönlicher Daten oder Ausführen von Code mit erweiterten Berechtigungen, wenn er von einem anderen Benutzer geöffnet wird. Alternativ kann der Angreifer die Daten auf dem Arbeitsblatt so ändern, dass sich dieses Arbeitsblatt nach dem Empfang durch das Opfer auf unerwartete Weise verhält. Durch Ändern der Werte, Formeln oder Darstellungsmerkmale eines mit Code verknüpften Arbeitsblatts wird es einem böswilligen Benutzer ermöglicht, einen anderen Benutzer durch Senden einer geänderten Datei anzugreifen. Außerdem können Benutzer durch Ändern von Werten auf dem Arbeitsblatt möglicherweise auf Informationen zugreifen, die nicht für sie bestimmt sind.

Da sowohl der Speicherort der Assembly als auch der des Dokuments über ausreichende Beweise verfügen müssen, damit die Ausführung erfolgt, ist dieser Angriff nicht leicht zu bewerkstelligen. Beispielsweise haben Dokumente in E-Mail-Anhängen oder auf nicht vertrauenswürdigen Intranetservern nicht genügend Berechtigungen, um ausgeführt zu werden.

Damit dieser Angriff möglich ist, muss der Code selbst so geschrieben sein, dass er Entscheidungen auf der Grundlage potenziell nicht vertrauenswürdiger Daten trifft. Ein Beispiel hierfür ist das Erstellen eines Arbeitsblatts mit einer ausgeblendeten Zelle, die den Namen eines Datenbankservers enthält. Der Benutzer übermittelt das Arbeitsblatt an eine ASPX-Seite, die versucht, mit der SQL-Authentifizierung und einem hardcodierten SA-Kennwort eine Verbindung zu diesem Server aufzubauen. Ein Angreifer könnte den Inhalt der ausgeblendeten Zelle durch einen anderen Computernamen ersetzen und so das SA-Kennwort abrufen. Um dieses Problem zu vermeiden, sollten Sie niemals Kennwörter hartcodieren und stets die Server-IDs vor dem Zugriff auf den Server mit einer internen Liste vertrauenswürdiger Server abgleichen.

Empfehlungen

  • Überprüfen Sie immer Eingaben und Daten, egal, ob sie vom Benutzer, aus dem Dokument, aus einer Datenbank, von einem Webdienst oder aus einer anderen Quelle stammen.

  • Achten Sie darauf, dass Sie bestimmte Arten von Funktionen nicht offen zugänglich machen, beispielsweise das Abrufen privilegierter Daten im Namen des Benutzers und Ablegen dieser Daten auf einem ungeschützten Arbeitsblatt.

  • Je nach Typ der Anwendung ist es möglicherweise sinnvoll, vor dem Ausführen von irgendwelchem Code zu überprüfen, ob das Originaldokument ausgeführt wird. Vergewissern Sie sich sich beispielsweise, dass der Code aus einem Dokument ausgeführt wird, das in einem bekannten, sicheren Speicherort gespeichert ist.

  • Eventuell ist es sinnvoll, beim Öffnen des Dokuments eine Warnung anzuzeigen, wenn Ihre Anwendung privilegierte Aktionen ausführt. Sie können zum Beispiel einen Begrüßungsbildschirm oder ein Startdialogfeld erstellen, in dem mitgeteilt wird, dass die Anwendung auf persönliche Daten zugreift, und dem Benutzer die Entscheidung zum Fortsetzen oder Abbrechen überlassen. Wenn ein Endbenutzer eine solche Warnung aus einem scheinbar unverfänglichen Dokument erhält, kann er die Anwendung beenden, bevor es irgendeine Beeinträchtigung gibt.

Code wird durch den Outlook-Objektmodellschutz gesperrt

In Microsoft Office kann verhindert werden, dass Code bestimmte Eigenschaften, Methoden und Objekte im Objektmodell verwendet. Durch Einschränken des Zugriffs auf diese Objekte verhindert Outlook, dass E-Mail-Würmer und -Viren das Objektmodell zu bösartigen Zwecken verwenden können. Dieses Sicherheitsfeature wird als Outlook-Objektmodellschutz bezeichnet. Wenn ein VSTO-Add-In versucht, eine beschränkte Eigenschaft oder Methode zu verwenden, während der Objektmodellschutz aktiviert ist, zeigt Outlook eine Sicherheitswarnung an, mit der der Benutzer den Vorgang abbrechen kann, oder gibt Outlook dem Benutzer die Möglichkeit, für eine begrenzte Zeit Zugriff auf die Eigenschaft oder Methode zuzulassen. Wenn der Benutzer den Vorgang beendet, lösen Outlook-VSTO-Add-Ins, die als Office-Projektmappen in Visual Studio erstellt wurden, eine COMExceptionaus.

Der Objektmodellschutz kann VSTO-Add-Ins auf unterschiedliche Weise beeinflussen, abhängig davon, ob Outlook mit Microsoft Exchange Server verwendet wird:

  • Wird Outlook ohne Exchange verwendet, kann ein Administrator den Objektmodellschutz für alle VSTO-Add-Ins auf dem Computer aktivieren bzw. deaktivieren.

  • Wenn Outlook mit Exchange verwendet wird, kann ein Administrator den Objektmodellschutz für alle VSTO-Add-Ins auf dem Computer aktivieren bzw. deaktivieren, oder er kann angeben, dass bestimmte VSTO-Add-Ins unabhängig vom Objektmodellschutz ausgeführt werden können. Administratoren können auch das Verhalten des Objektmodellschutzes für bestimmte Bereiche des Objektmodells ändern. So können Administratoren beispielsweise VSTO-Add-Ins automatisch erlauben, programmgesteuert E-Mail-Nachrichten zu senden, auch wenn der Objektmodellschutz aktiviert ist.

    Beginnend mit Outlook 2007 wurde das Verhalten des Objektmodellschutzes geändert, um die Entwickler- und Benutzerfreundlichkeit zu verbessern, aber gleichzeitig Outlook zu schützen. Weitere Informationen finden Sie unter Code Security Changes in Outlook 2007.

Minimieren der Warnungen vom Objektmodellschutz

Damit Sicherheitswarnungen vermieden werden, wenn Sie beschränkte Eigenschaften und Methoden verwenden, müssen Sie sicherstellen, dass das VSTO-Add-In Outlook-Objekte aus dem Application -Feld der ThisAddIn -Klasse im Projekt abruft. Weitere Informationen über dieses Feld finden Sie unter Program VSTO Add-Ins.

Nur Outlook-Objekten, die aus diesem Objekt abgerufen wurden, kann vom Objektmodellschutz vertraut werden. Im Gegensatz dazu sind Objekte, die aus einem neuen Microsoft.Office.Interop.Outlook.Application-Objekt abgerufen wurden, nicht vertrauenswürdig, sodass die beschränkten Eigenschaften und Methoden Sicherheitswarnungen auslösen, wenn der Objektmodellschutz aktiviert ist.

Im folgenden Codebeispiel wird eine Sicherheitswarnung angezeigt, wenn der Objektmodellschutz aktiviert wird. Die To-Eigenschaft der Microsoft.Office.Interop.Outlook.MailItem-Klasse wird durch den Objektmodellschutz beschränkt. Das Microsoft.Office.Interop.Outlook.MailItem Objekt ist nicht vertrauenswürdig, da der Code es von einem Microsoft.Office.Interop.Outlook.Application Objekt abruft, das mithilfe des neuen Operators erstellt wird, anstatt es aus dem Application Feld zu erhalten.

private void UntrustedCode()
{
    Microsoft.Office.Interop.Outlook.Application application =
        new Microsoft.Office.Interop.Outlook.Application();
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        application.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

Im folgenden Codebeispiel wird veranschaulicht, wie die eingeschränkte To-Eigenschaft eines Microsoft.Office.Interop.Outlook.MailItem-Objekts verwendet wird, das vom Objektmodellschutz als vertrauenswürdig eingestuft wird. Im Code wird das vertrauenswürdige Application-Feld verwendet, um das Microsoft.Office.Interop.Outlook.MailItem-Objekt abzurufen.

private void TrustedCode()
{
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        this.Application.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

Hinweis

Wenn Outlook mit Exchange verwendet wird, ist es nicht möglich, durch ein Abrufen aller Outlook-Objekte aus ThisAddIn.Application sicherzustellen, dass Ihr VSTO-Add-In auf das gesamte Outlook-Objektmodell zugreifen kann. Wenn beispielsweise ein Exchange-Administrator Outlook so festlegt, dass alle Versuche, mithilfe des Outlook-Objektmodells auf Adressinformationen zuzugreifen, automatisch verweigert werden, lässt Outlook das vorherige Codebeispiel nicht für den Zugriff auf die To-Eigenschaft zu, obwohl im Codebeispiel das vertrauenswürdige ThisAddIn.Application Feld verwendet wird.

Angeben, welche Add-Ins vertrauenswürdig sind, wenn Exchange verwendet wird

Wenn Outlook mit Exchange verwendet wird, können Administratoren angeben, dass bestimmte VSTO-Add-Ins unabhängig vom Objektmodellschutz ausgeführt werden können. Outlook-VSTO-Add-Ins, die als Office-Projektmappen in Visual Studio erstellt wurden, können nicht einzeln als vertrauenswürdig festgelegt werden, sondern nur als Gruppe.

Outlook vertraut einem VSTO-Add-In anhand eines Hashcodes der Einstiegspunkt-DLL des VSTO-Add-Ins. Alle Outlook VSTO-Add-Ins, die auf die Visual Studio-Tools für Office-Runtime abzielen, verwenden dieselbe Einstiegspunkt-DLL (VSTOLoader.dll). Dies bedeutet, dass, wenn ein Administrator jedem VSTO-Add-In, dessen Ziel die Visual Studio Tools for Office-Laufzeit ist, vertraut, dass es ohne Auftreten des Objektmodellschutzes ausgeführt werden kann, auch alle anderen VSTO-Add-Ins, die auf die Visual Studio Tools for Office-Laufzeit abzielen, als vertrauenswürdig eingestuft werden. Weitere Informationen zu Vertrauensstellungen für spezielle VSTO-Add-Ins, damit diese unabhängig vom Objektmodellschutz ausgeführt werden können, finden Sie unter Angeben der Methode zur Verwaltung von Virenschutzfeatures in Outlook.

Berechtigungsänderungen werden nicht sofort wirksam

Wenn der Administrator Berechtigungen für ein Dokument oder eine Assembly ändert, müssen die Benutzer alle Office-Anwendungen beenden und dann neu starten, damit die Änderungen wirksam werden.

Andere Anwendungen, die als Host für Microsoft Office-Anwendungen fungieren, können ebenfalls verhindern, dass die neuen Berechtigungen wirksam werden. Benutzer sollten alle Anwendungen beenden, die Office verwenden (gehostete oder eigenständige), wenn die Sicherheitsrichtlinien geändert wurden.

Trust Center-Einstellungen im Microsoft Office-System wirken sich weder auf Add-Ins noch auf Anpassungen auf Dokumentebene aus

Benutzer können verhindern, dass VSTO-Add-Ins geladen werden, indem sie eine Option im Trust Centerfestlegen. Allerdings wirken sich diese Vertrauenseinstellungen nicht auf VSTO-Add-Ins aus, die als Office-Projektmappen in Visual Studio erstellt wurden.

Wenn Benutzer das Laden von VSTO-Add-Ins über das Trust Centerverhindern, werden die folgenden Typen von VSTO-Add-Ins nicht geladen:

  • Verwaltete und nicht verwaltete COM-VSTO Add-Ins

  • Verwaltete und nicht verwaltete SmartDocuments

  • Verwaltete und nicht verwaltete Automatisierungs-VSTO Add-Ins

  • Verwaltete und nicht verwaltete Echtzeitdatenkomponenten

    Die folgenden Verfahren beschreiben, wie Benutzer das Trust Center verwenden können, um zu verhindern, dass VSTO-Add-Ins in Microsoft und Microsoft Office 2010 geladen werden. Diese Verfahren wirken sich nicht auf VSTO-Add-Ins oder Anpassungen aus, die mit den Office-Entwicklungstools in Visual Studio erstellt wurden.

So deaktivieren Sie VSTO-Add-Ins in Microsoft Office 2010- und Microsoft Office 2013-Anwendungen

  1. Wählen Sie die Registerkarte Datei aus.

  2. Wählen Sie die Schaltfläche ApplicationName-Optionen aus.

  3. Wählen Sie im Kategorienbereich den Eintrag Trust Centeraus.

  4. Wählen Sie im Detailbereich die Option Einstellungen für das Trust Centeraus.

  5. Wählen Sie im Kategorienbereich den Eintrag Add-Insaus.

  6. Wählen Sie im Detailbereich die Option Anwendungs-Add-Ins müssen von einem vertrauenswürdigen Herausgeber signiert sein oder Alle Anwendungs-Add-Ins deaktivierenaus.

Zugehöriger Inhalt