Überlegungen zur Sicherheit von Office-Projektmappen
Aktualisiert: November 2007
Die von Microsoft .NET Framework, Microsoft Office 2003 und 2007 Microsoft Office System bereitgestellten Sicherheitsfeatures können in Visual Studio Tools for 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 Visual Studio Tools for Office-Projektmappen beeinflussen.
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 Outlook 2003 und Microsoft Office Outlook 2007 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.
Weitere Informationen zum Outlook-Objektmodellschutz in Outlook 2003 sowie eine Liste der eingeschränkten Methoden und Eigenschaften finden Sie unter What's New in Microsoft Office Outlook 2003 for Developers?. Weitere Informationen zu Outlook-Sicherheitseinstellungen für Exchange-Administratoren finden Sie unter Customizing Outlook 2003 to Help Prevent Viruses.
.gif "Hinweis") Hinweis: |
|---|
Mit Outlook 2007 wurden verschiedene Änderungen im Verhalten des Schutzes für das Objektmodell eingeführt, 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 new-Operator 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. |
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 mit Visual Studio Tools for Office erstellten Outlook-Add-Ins verwenden dieselbe Einstiegspunkt-DLL (AddinLoader.dll für Outlook 2003-Add-Ins; VSTOLoader.dll für Outlook 2007-Add-Ins). Wenn also ein Administrator alle Add-Ins, die mithilfe von Visual Studio Tools for Office erstellt wurden, für die Ausführung ohne Objektmodellschutz als vertrauenswürdig behandelt, werden auch alle anderen Add-Ins, die mit Visual Studio Tools for Office erstellt werden, als vertrauenswürdig behandelt. Weitere Informationen zu Vertrauensstellungen für spezielle Add-Ins, damit diese unabhängig vom Objektmodellschutz ausgeführt werden können, finden Sie unter Customizing Outlook 2003 to Help Prevent Viruses.
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 Vertrauensstellungscenter in 2007 Microsoft Office System wirken sich auf Add-Ins oder Anpassungen auf Dokumentebene nicht aus
Benutzer können verhindern, dass Add-Ins geladen werden, indem eine Option im Vertrauensstellungscenter 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 Vertrauensstellungscenter 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.
Die folgenden Prozeduren beschreiben, wie das Laden von Add-Ins in 2007 Microsoft Office System über das Vertrauensstellungscenter 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 Excel 2007, PowerPoint 2007 oder Word 2007
Klicken Sie auf die Schaltfläche für Microsoft Office.
Klicken Sie auf die Schaltfläche ApplicationName-Optionen.
Klicken Sie im Bereich Kategorien auf Vertrauensstellungscenter.
Klicken Sie im Detailbereich auf Einstellungen für das Vertrauensstellungscenter.
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 oder Visio 2007
Klicken Sie im Menü Extras auf Vertrauensstellungscenter.
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
Konzepte
Sicherheit in Office-Projektmappen (2007 System)