Überlegungen zur Sicherheit von Office-Projektmappen

Artikel
08/10/2011

Die von Microsoft .NET Framework und Microsoft Office bereitgestellten Sicherheitsfunktionen können in Office-Projektmappen zum Schutz vor möglichen Sicherheitsbedrohungen beitragen. Dieses Thema erläutert einige dieser Bedrohungen und stellt Empfehlungen bereit, die Unterstützung beim Schutz vor diesen Bedrohungen bieten. Es schließt auch Informationen dazu ein, wie Microsoft Office-Sicherheitseinstellungen Office-Projektmappen beeinflussen.

Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokument- und Anwendungsebene für Microsoft Office 2010 und 2007 Microsoft Office System. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Vertrauenswürdiger Code wird für die Verwendung in einem neuen, bösartigen Dokument ausgenutzt

Ein Angreifer könnte vertrauenswürdigen Code, der für einen bestimmten Zweck gedacht ist (etwa für das Herunterladen persönlicher Daten für eine Bewerbung), in einem anderen Dokument verwenden (zum Beispiel in einem Arbeitsblatt). Für den Code ist nicht erkennbar, dass nicht das ursprüngliche Dokument ausgeführt wird. Außerdem können sich beim Öffnen durch einen anderen Benutzer weitere Gefahren ergeben (z. B. Offenlegung persönlicher Daten oder Ausführung von Code mit erweiterten Berechtigungen). Alternativ kann der Angreifer einfach die Daten in einem Arbeitsblatt so ändern, dass sich dieses Arbeitsblatt nach dem Empfang durch das Opfer auf unerwartete Weise verhält. Durch Ändern der Werte, Formeln oder Präsentationsmerkmale eines mit Code verknüpften Arbeitsblattes und durch den Versand der geänderten Datei kann ein böswilliger Benutzer einen anderen Benutzer angreifen. Außerdem können Benutzer durch Ändern der Werte in 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. Dokumente in E-Mail-Anhängen etwa oder auf nicht vertrauenswürdigen Intranetservern weisen nicht genügend Berechtigungen auf, 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 die Server-IDs vor dem Zugriff auf den Server stets mit einer internen Liste vertrauenswürdiger Server abgleichen.

Empfehlungen

Überprüfen Sie grundsätzlich alle Daten, ob sie nun vom Benutzer, dem Dokument, einer Datenbank, einem Webserver oder aus einer anderen Quelle stammen.
Achten Sie darauf, dass Sie bestimmte Arten von Funktionen nicht offen zugänglich machen, wie zum Beispiel das Abrufen persönlicher Daten im Namen des Benutzers und das Speichern in einem ungeschützten Arbeitsblatt.
Je nach Art der Anwendung macht es u. U. Sinn, sich vor der Ausführung von Code zu vergewissern, dass das Originaldokument ausgeführt wird (vergewissern Sie sich beispielsweise, dass der Code von einem Dokument ausgeführt wird, das in einem bekannten, sicheren Verzeichnis gespeichert ist).
Eventuell ist es sinnvoll, beim Öffnen des Dokuments eine Warnung anzuzeigen, wenn Ihre Anwendung privilegierte Aktionen durchführt. Sie können zum Beispiel einen Begrüßungsbildschirm mit dem Hinweis erstellen, dass die Anwendung auf persönliche Daten zugreift, und dem Benutzer die Entscheidung zum Fortfahren oder Abbrechen überlassen. Wenn in einem scheinbar unverfänglichen Dokument ein solcher Hinweis angezeigt wird, kann der Endbenutzer die Anwendung beenden, ehe etwas mit den Daten geschieht.

Code wird vom Outlook-Objektmodellschutz gesperrt

In Microsoft Office kann verhindert werden, dass Code bestimmte Eigenschaften, Methoden und Objekte im Objektmodell verwendet. Durch das Einschränken des Zugriffs auf diese Objekte verhindert Outlook das Verwenden des Objektmodells durch E-Mail-Würmer und Viren zu bösartigen Zwecken. Dieses Sicherheitsfeature wird als Outlook-Objektmodellschutz bezeichnet. Wenn ein 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. Der Benutzer kann den Zugriff auf die Eigenschaft oder Methode aber auch für eine begrenzte Zeit zulassen. Wenn der Benutzer den Vorgang beendet, lösen mit Visual Studio Tools for Office erstellte Outlook-Add-Ins eine COMException aus.

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

Wenn Outlook ohne Exchange verwendet wird, kann ein Administrator den Objektmodellschutz für alle Add-Ins auf dem Computer aktivieren bzw. deaktivieren.
Wenn Outlook mit Exchange verwendet wird, kann ein Administrator den Objektmodellschutz für alle Add-Ins auf dem Computer aktivieren bzw. deaktivieren, oder er kann angeben, dass bestimmte 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 Add-Ins erlauben, programmgesteuert E-Mail-Nachrichten zu senden, auch wenn der Objektmodellschutz aktiviert ist.

Mit Outlook 2007 wird das Verhalten des Schutzes für das Objektmodell so geändert, sodass Outlook von Entwicklern und Benutzern besser gesichert werden kann. Weitere Informationen finden Sie unter Code Security Changes in Outlook 2007.

Minimieren der Warnungen vom Objektmodellschutz

Um Sicherheitswarnungen bei der Verwendung beschränkter Eigenschaften und Methoden zu verhindern, müssen Sie sicherstellen, dass das Add-In Outlook-Objekte aus dem Application-Feld der ThisAddIn-Klasse im Projekt abruft. Weitere Informationen über dieses Tool finden Sie unter Programmieren von Add-Ins auf Anwendungsebene.

Nur von diesem Objekt abgerufene Outlook-Objekte sind für den Schutz des Objektmodells vertrauenswürdig. Im Gegensatz dazu sind Objekte, die von einem neuen Microsoft.Office.Interop.Outlook.Application-Objekt abgerufen werden, 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 dieses von einer Microsoft.Office.Interop.Outlook.Application abruft, die mit dem Operator new erstellt wurde, und nicht aus dem Application-Feld.

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

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 die Verwendung der beschränkten To-Eigenschaft eines Microsoft.Office.Interop.Outlook.MailItem-Objekts veranschaulicht, das für den Objektmodellschutz vertrauenswürdig ist. Im Code wird das vertrauenswürdige Application-Feld verwendet, um den Microsoft.Office.Interop.Outlook.MailItem abzurufen.

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

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

Tipp

Wenn Outlook mit Exchange verwendet wird, kann beim Abrufen aller Outlook-Objekte von ThisAddIn.Application das Add-In nicht unbedingt auf das gesamte Outlook-Objektmodell zugreifen. Wenn ein Exchange-Administrator Outlook für das automatische Ablehnen aller Zugriffsversuche auf Adressinformationen über das Outlook-Objektmodell festlegt, lässt Outlook den Zugriff auf die To-Eigenschaft durch das vorherige Codebeispiel nicht zu, obwohl im Codebeispiel das vertrauenswürdige ThisAddIn.Application-Feld verwendet wird.

Angeben der vertrauenswürdigen Add-Ins bei der Verwendung von Exchange

Wenn Outlook mit Exchange verwendet wird, können Administratoren angeben, dass bestimmte Add-Ins unabhängig vom Objektmodellschutz ausgeführt werden können. Mit Visual Studio Tools for Office erstellten Outlook-Add-Ins kann nicht einzeln Vertrauenswürdigkeit gewährt werden. Dies ist nur als Gruppe möglich.

Outlook behandelt ein Add-In basierend auf einem Hashcode der Einstiegspunkt-DLL des Add-Ins als vertrauenswürdig. Alle Outlook-Add-Ins mit der Zielversion Visual Studio Tools for Office-Laufzeit verwenden die gleiche Einstiegspunkt-DLL (VSTOLoader.dll). Wenn ein Administrator ein Add-In mit der Zielversion Visual Studio Tools for Office-Laufzeit als vertrauenswürdig für die Ausführung ohne den Objektmodellschutz festlegt, sind somit auch alle anderen Add-Ins mit der Zielversion Visual Studio Tools for Office-Laufzeit vertrauenswürdig. Weitere Informationen zu Vertrauensstellungen für spezielle 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 die 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. Wenn die Sicherheitsrichtlinien geändert werden, müssen die Benutzer alle Anwendungen beenden, die Office (als Host oder eigenständig) verwenden.

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

Benutzer können verhindern, dass Add-Ins geladen werden, indem eine Option im Sicherheitscenter festgelegt wird. Add-Ins auf Anwendungsebene und Anpassungen auf Dokumentebene, die unter Verwendung von Visual Studio Tools for Office erstellt werden, werden von diesen Einstellungen für die Vertrauensstellung jedoch nicht beeinflusst.

Wenn Benutzer das Laden von Add-Ins über das Sicherheitscenter verhindern, werden die folgenden Typen von Add-Ins nicht geladen:

Verwaltete und nicht verwaltete COM-Add-Ins.
Verwaltete und nicht verwaltete Smarttags.
Verwaltete und nicht verwaltete SmartDocuments.
Verwaltete und nicht verwaltete Automatisierungs-Add-Ins.
Verwaltete und nicht verwaltete Echtzeitdatenkomponenten.

Tipp

Smarttags sind in Excel 2010 und Word 2010 veraltet. Weitere Informationen finden Sie unter Übersicht über Smarttags.

Die folgenden Prozeduren beschreiben, wie das Laden von Add-Ins in 2007 Microsoft Office System über das Sicherheitscenter beschränkt werden kann. Diese Prozeduren beeinflussen keine Add-Ins oder Anpassungen, die unter Verwendung von Visual Studio Tools for Office erstellt wurden.

So deaktivieren Sie Add-Ins in Microsoft Office 2010-Anwendungen, Excel 2007, PowerPoint 2007 oder Word 2007

Klicken Sie auf die Registerkarte Datei (für Microsoft Office 2010-Anwendungen) oder auf die Microsoft Office-Schaltfläche (für 2007 Microsoft Office-Anwendungen).
Klicken Sie auf die Schaltfläche ApplicationName-Optionen.
Klicken Sie im Bereich "Kategorien" auf Sicherheitscenter.
Klicken Sie im Detailbereich auf Einstellungen für das Sicherheitscenter.
Klicken Sie im Bereich Kategorien auf Add-Ins.
Wählen Sie im Detailbereich Anwendungs-Add-Ins müssen von einem vertrauenswürdigen Herausgeber signiert sein oder Alle Anwendungs-Add-Ins deaktivieren aus.

So deaktivieren Sie Add-Ins in InfoPath 2007, Outlook 2007, Project 2007 oder Visio 2007

Klicken Sie im Menü Extras auf Sicherheitscenter.
Klicken Sie im Bereich Kategorien auf Makrosicherheit.
Wählen Sie im Detailbereich Keine Warnungen und alle Makros deaktivieren oder Warnungen für signierte Makros. Alle nicht signierten Makros sind deaktiviert aus.
Klicken Sie im Bereich Kategorien auf Add-Ins.
Wählen Sie im Detailbereich Makrosicherheitseinstellungen für installierte Add-Ins übernehmen aus.

Siehe auch

Weitere Ressourcen

Sichern von Office-Projektmappen

Freigeben über