Überlegungen zur Sicherheit von Office-Projektmappen

Artikel
02/26/2013

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 auf Anwendungsebene für Office 2013 und Office 2010. 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 beispielsweise impliziert wird persönliche Informationen für eine Beschäftigungs-Anwendung herunter, und in einem anderen Dokument, wie einem Arbeitsblatt wiederverwenden.Der Code ist nicht, dass das ursprüngliche Dokument ausgeführt, und Außerdem möglicherweise andere Bedrohungen, wie Offenlegung persönlicher Daten oder Ausführencode mit erhöhten Rechten, wenn er durch einen anderen Benutzer geöffnet wird.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 immer Eingaben und Daten, ob sie vom Benutzer, dem Dokument, einer Datenbank, einem Webdienst 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 Typ der Anwendung, ist es möglicherweise sinnvoll, um zu überprüfen, ob das Originaldokument ausgeführt wird, bevor Code ausführt.Stellen Sie sicher, dass sie von einem Dokument ausgeführt wird, das an einem bekannten gespeichert wird, sicheren Ort.
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 Outlook-Add-Ins, die erstellt werden, indem sie Office-Projektmappen in Visual Studio verwenden, 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.

Ab Outlook 2007, ist das Verhalten des Objektmodellschutzes geändert, um den Entwickler und Benutzerfreundlichkeit und gleichzeitig zu verbessern, Outlook zu sichern.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);
}

Hinweis
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.

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.Outlook-Add-Ins, die erstellt werden, indem Office-Projektmappen in Visual Studio, können nicht einzeln Vertrauenswürdigkeit werden; Sie können nur als Gruppe vertraut machen.

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 für Office-Laufzeit verwenden die gleiche Einstiegspunkt-DLL (VSTOLoader.dll).Wenn ein Administrator ein Add-In mit der Zielversion Visual Studio-Tools für 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 für 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 erstellt werden, indem Office-Projektmappen in Visual Studio, nicht von diesen Einstellungen für die Vertrauensstellung 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 SmartDocuments.
Verwaltete und nicht verwaltete Automatisierungs-Add-Ins.
Verwaltete und nicht verwaltete Echtzeitdatenkomponenten.

Die folgenden Prozeduren beschreiben, wie Benutzer Sicherheitscenter verwenden können, um Add-Ins aus dem Laden in Microsoft Office 2013 und Microsoft Office 2010 einzuschränken.Diese Prozeduren beeinflussen keine Add-Ins oder Anpassungen, die mit den Office-Entwicklungstools in Visual Studio erstellt wurden, verwenden.

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

Wählen Sie die Registerkarte aus. Datei
Wählen Sie die Schaltfläche Anwendungsname Optionen aus.
Im Bereich wählen Sie Sicherheitscenter aus.
Wählen Sie im Detailbereich Einstellungen für das Sicherheitscenter aus.
Im Bereich wählen Sie Add-Ins aus.
Wählen Sie im Detailbereich Anwendungs-Add-Ins müssen von einem vertrauenswürdigen Herausgeber signiert sein oder Alle Anwendungs-Add-Ins deaktivieren aus.

Siehe auch

Weitere Ressourcen

Sichern von Office-Projektmappen

Freigeben über