Spezifische Sicherheitsüberlegungen für Office-Lösungen

Die sicherheitsrelevanten Features von Microsoft .NET Framework und Microsoft Office können dazu beitragen, Ihre Office-Lösungen vor möglichen Sicherheitsbedrohungen zu schützen. In diesem Thema werden einige dieser Bedrohungen erläutert und Empfehlungen zum Schutz vor ihnen bereitgestellt. Sie enthält auch Informationen dazu, wie sich Die Sicherheitseinstellungen von Microsoft Office auf Office-Lösungen auswirken.

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

Vertrauenswürdiger Code wird in einem neuen, bösartigen Dokument neu verwendet.

Ein Angreifer kann vertrauenswürdigen Code verwenden, der für einen bestimmten Zweck vorgesehen ist, z. B. das Herunterladen von persönlichen Informationen für eine Bewerbung und die Wiederverwendung in einem anderen Dokument, z. B. einem Arbeitsblatt. Der Code weiß nicht, dass das ursprüngliche Dokument nicht ausgeführt wird, und kann andere Bedrohungen öffnen, z. B. das Einblenden von persönlichen Informationen oder das Ausführen von Code mit erhöhten Berechtigungen, wenn es von einem anderen Benutzer geöffnet wird. Alternativ kann der Angreifer die Daten im Arbeitsblatt so ändern, dass er sich unerwartet verhält, wenn er an das Opfer gesendet wird. Durch Ändern der Werte, Formeln oder Darstellungsmerkmale eines Arbeitsblatts, das mit Code verknüpft ist, ist es möglich, dass ein böswilliger Benutzer einen anderen Benutzer durch Senden einer geänderten Datei angreifen kann. Es kann auch möglich sein, dass Benutzer auf Informationen zugreifen können, die nicht angezeigt werden sollen, indem Sie Werte im Arbeitsblatt ändern.

Weil sowohl der Assemblyspeicherort als auch der Dokumentspeicherort über ausreichende Nachweise verfügen müssen, ist dieser Angriff nicht einfach durchzuführen. Beispielsweise verfügen Dokumente in E-Mail-Anlagen oder auf nicht vertrauenswürdigen Intranetservern nicht über ausreichende Berechtigungen zum Ausführen.

Um diesen Angriff möglich zu machen, muss der Code selbst so geschrieben werden, dass er Entscheidungen auf der Grundlage potenziell nicht vertrauenswürdiger Daten trifft. Ein Beispiel ist das Erstellen eines Arbeitsblatts mit einer ausgeblendeten Zelle, die den Namen eines Datenbankservers enthält. Der Benutzer sendet das Arbeitsblatt an eine ASPX-Seite, die versucht, eine Verbindung mit diesem Server mithilfe der SQL-Authentifizierung und einem hartcodierten SA-Kennwort herzustellen. Ein Angreifer könnte den Inhalt der ausgeblendeten Zelle durch einen anderen Computernamen ersetzen und das SA-Kennwort abrufen. Um dieses Problem zu vermeiden, sollten Sie niemals Passwörter hartcodieren; und überprüfen Sie immer die Server-IDs anhand einer internen Liste von vertrauenswürdigen Servern, bevor Sie auf den Server zugreifen.

Recommendations

• Überprüfen Sie immer Eingaben und Daten, unabhängig davon, ob sie vom Benutzer, dem Dokument, einer Datenbank, einem Webdienst oder einer anderen Quelle stammt.

• Achten Sie darauf, bestimmte Arten von Funktionen verfügbar zu machen, z. B. das Abrufen privilegierter Daten im Namen des Benutzers und das Einfügen in ein nicht geschütztes Arbeitsblatt.

• Je nach Anwendungstyp kann es sinnvoll sein, zu überprüfen, ob das ursprüngliche Dokument ausgeführt wird, bevor Code ausgeführt wird. Überprüfen Sie beispielsweise, ob es von einem Dokument ausgeführt wird, das an einem bekannten, sicheren Speicherort gespeichert ist.

• Es kann sinnvoll sein, eine Warnung anzuzeigen, wenn das Dokument geöffnet wird, wenn Ihre Anwendung privilegierte Aktionen ausführt. Sie könnten beispielsweise einen Begrüßungsbildschirm oder ein Startdialogfeld erstellen, das angibt, dass die Anwendung auf persönliche Daten zugreifen wird, und dem Benutzer die Entscheidung geben, den Vorgang fortzusetzen oder abzubrechen. Wenn ein Endbenutzer eine solche Warnung von einem scheinbar unschuldigen Dokument erhält, kann er die Anwendung beenden, bevor etwas kompromittiert wird.

Code wird durch den Outlook-Objektmodellschutz blockiert.

Microsoft Office kann die Verwendung bestimmter Eigenschaften, Methoden und Objekte im Objektmodell einschränken. Durch das Einschränken des Zugriffs auf diese Objekte hilft Outlook, E-Mail-Würmer und Viren daran zu hindern, das Objektmodell zu böswilligen Zwecken zu verwenden. Dieses Sicherheitsfeature wird als Outlook-Objektmodellschutz bezeichnet. Wenn ein VSTO-Add-In versucht, eine eingeschränkte Eigenschaft oder Methode zu verwenden, während der Objektmodellschutz aktiviert ist, zeigt Outlook eine Sicherheitswarnung an, mit der der Benutzer den Vorgang beenden kann oder dem Benutzer den Zugriff auf die Eigenschaft oder Methode für einen begrenzten Zeitraum gewähren kann. Wenn der Benutzer den Vorgang beendet, lösen Outlook VSTO-Add-Ins, die mithilfe von Office-Lösungen in Visual Studio erstellt wurden, ein COMException aus.

Der Objektmodellschutz kann sich auf verschiedene Arten auf VSTO-Add-Ins auswirken, je nachdem, ob Outlook mit Microsoft Exchange Server verwendet wird:

• Wenn Outlook nicht mit Exchange verwendet wird, kann ein Administrator den Objektmodellschutz für alle VSTO-Add-Ins auf dem Computer aktivieren oder deaktivieren.

• Wenn Outlook mit Exchange verwendet wird, kann ein Administrator den Objektmodellschutz für alle VSTO-Add-Ins auf dem Computer aktivieren oder deaktivieren, oder der Administrator kann angeben, dass bestimmte VSTO-Add-Ins ausgeführt werden können, ohne auf den Objektmodellschutz zu stoßen. Administratoren können auch das Verhalten des Objektmodellschutzes für bestimmte Bereiche des Objektmodells ändern. Administratoren können z. B. automatisch zulassen, dass VSTO-Add-Ins programmgesteuert E-Mails senden, auch wenn der Objektmodellschutz aktiviert ist.

  Ab Outlook 2007 wurde das Verhalten des Objektmodellschutzes geändert, um die Entwickler- und Benutzerfreundlichkeit zu verbessern und gleichzeitig die Sicherheit von Outlook zu gewährleisten. Weitere Informationen finden Sie unter Codesicherheitsänderungen in Outlook 2007.

Minimieren von Warnungen zum Schutz des Objektmodells

Um Sicherheitswarnungen zu vermeiden, wenn Sie eingeschränkte Eigenschaften und Methoden verwenden, stellen Sie sicher, dass Ihr VSTO-Add-In Outlook-Objekte aus dem Application Feld der ThisAddIn Klasse in Ihrem Projekt abruft. Weitere Informationen zu diesem Feld finden Sie unter "Programm-VSTO-Add-Ins".

Nur von diesem Objekt abgerufene Outlook-Objekte können vom Objektmodellschutz als vertrauenswürdig eingestuft werden. Im Gegensatz dazu werden Objekte, die aus einem neuen Microsoft.Office.Interop.Outlook.Application Objekt abgerufen werden, nicht vertrauenswürdig, und die eingeschränkten Eigenschaften und Methoden lösen Sicherheitswarnungen aus, wenn der Objektmodellschutz aktiviert ist.

Im folgenden Codebeispiel wird eine Sicherheitswarnung angezeigt, wenn der Objektmodellschutz aktiviert ist. Die To Eigenschaft der Microsoft.Office.Interop.Outlook.MailItem Klasse wird durch den Objektmodellschutz eingeschrä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);
}

Private Sub UntrustedCode()
    Dim application As New Microsoft.Office.Interop.Outlook.Application
    Dim mailItem1 As Microsoft.Office.Interop.Outlook.MailItem = _
        TryCast(application.CreateItem( _
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem),  _
        Microsoft.Office.Interop.Outlook.MailItem)
    mailItem1.To = "someone@example.com"
    MessageBox.Show(mailItem1.To)
End Sub

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. Der Code nutzt das Application-Feld im Vertrauen, um das Microsoft.Office.Interop.Outlook.MailItem zu erhalten.

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);
}

Private Sub TrustedCode()
    Dim mailItem1 As Microsoft.Office.Interop.Outlook.MailItem = _
        TryCast(Me.Application.CreateItem( _
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem),  _
        Microsoft.Office.Interop.Outlook.MailItem)
    mailItem1.To = "someone@example.com"
    MessageBox.Show(mailItem1.To)
End Sub

Angeben, welche Add-Ins bei Verwendung von Exchange als vertrauenswürdig festgelegt werden sollen

Wenn Outlook mit Exchange verwendet wird, können Administratoren angeben, dass bestimmte VSTO-Add-Ins ausgeführt werden können, ohne auf den Objektmodellschutz zu stoßen. Outlook-VSTO-Add-Ins, die mit Office-Lösungen in Visual Studio erstellt wurden, können nicht einzeln als vertrauenswürdig eingestuft werden. sie können nur als Gruppe als vertrauenswürdig eingestuft werden.

Outlook vertraut einem VSTO-Add-In basierend auf einem Hashcode der Einstiegspunkt-DLL des VSTO-Add-Ins. Alle Outlook-VSTO-Add-Ins, die auf die Visual Studio-Tools für Office-Laufzeit abzielen, verwenden die gleiche Einstiegspunkt-DLL (VSTOLoader.dll). Dies bedeutet, dass, wenn ein Administrator einem VSTO-Add-In vertraut, das auf die Laufzeit von Visual Studio Tools für Office abzielt, ohne auf den Objektmodellschutz zu stoßen, alle anderen VSTO-Add-Ins, die auf die Visual Studio Tools for Office-Laufzeit abzielen, ebenfalls vertrauenswürdig sind. Weitere Informationen, um bestimmten VSTO-Add-Ins vertrauensvoll auszuführen, ohne auf den Objektmodellschutz zu stoßen, finden Sie unter Angeben der Methode, die Outlook zum Verwalten von Virenabwehrfunktionen verwendet.

Berechtigungsänderungen werden nicht sofort wirksam

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

Andere Anwendungen, die Microsoft Office-Anwendungen hosten, können auch verhindern, dass die neuen Berechtigungen erzwungen werden. Benutzer sollten alle Anwendungen beenden, die Office verwenden, gehostet oder eigenständig sind, wenn Sicherheitsrichtlinien geändert werden.

Einstellungen für das Trust Center im Microsoft Office-System wirken sich nicht auf Add-Ins oder Anpassungen auf Dokumentebene aus

Benutzer können verhindern, dass VSTO-Add-Ins geladen werden, indem sie eine Option im Trust Center festlegen. VSTO-Add-Ins und Anpassungen auf Dokumentebene, die mit Office-Lösungen in Visual Studio erstellt wurden, sind jedoch von diesen Vertrauenseinstellungen nicht betroffen.

Wenn der Benutzer verhindert, dass VSTO-Add-Ins mithilfe des Trust Centers geladen werden, werden die folgenden VSTO-Add-Ins nicht geladen:

• Verwaltete und nicht verwaltete COM-VSTO-Add-Ins.

• Verwaltete und nicht verwaltete intelligente Dokumente.

• 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 das Laden von VSTO-Add-Ins in Microsoft Office 2013 und Microsoft Office 2010 einzuschränken. Diese Verfahren wirken sich nicht auf VSTO-Add-Ins oder Anpassungen aus, die mit 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 Bereich "Kategorien" die Option "Trust Center" aus.

4. Wählen Sie im Detailbereich die Einstellungen für das Trust Center aus.

5. Wählen Sie im Bereich "Kategorien" die Option "Add-Ins" aus.

6. Wählen Sie im Detailbereich die Option " Anwendungs-Add-Ins erforderlich" aus, um von vertrauenswürdigen Herausgebern signiert zu sein , oder deaktivieren Sie alle Anwendungs-Add-Ins.

Verwandte Inhalte

• Sichere Office-Lösungen