Spezifische Sicherheitsüberlegungen für Office-Lösungen
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 features available by Office-App lication and project type.
Vertrauenswürdiger Code wird in einem neuen, bösartigen Dokument neu verwendet.
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 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 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 blockiert.
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 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 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. Administratoren können z. B. automatisch zulassen, dass VSTO-Add-Ins programmgesteuert E-Mails 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 Codesicherheitsänderungen in Outlook 2007.
Minimieren von Warnungen zum Schutz des Objektmodells
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 zu diesem Feld finden Sie unter "Programm-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 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 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 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 dieselbe Einstiegspunkt-DLL (VSTOLoader.dll). Dies bedeutet, dass, wenn ein Administrator einem VSTO-Add-In vertraut, das auf die Visual Studio-Tools für Office-Laufzeit ausgerichtet ist, ohne auf den Objektmodellschutz zu stoßen, alle anderen VSTO-Add-Ins, die auf die Visual Studio-Tools für Office-Laufzeit abzielen, ebenfalls vertrauenswürdig sind. 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.
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 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 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 den Office-Entwicklungstools in Visual Studio erstellt wurden.
So deaktivieren Sie VSTO-Add-Ins in Microsoft Office 2010- und Microsoft Office 2013-Anwendungen
Wählen Sie die Registerkarte Datei aus.
Wählen Sie die Schaltfläche "ApplicationName-Optionen" aus .
Wählen Sie im Kategorienbereich den Eintrag Trust Centeraus.
Wählen Sie im Detailbereich die Option Einstellungen für das Trust Centeraus.
Wählen Sie im Kategorienbereich den Eintrag Add-Insaus.
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.