Considérations spécifiques sur la sécurité pour les solutions Office

Article
08/10/2011

Les fonctionnalités de sécurité fournies par Microsoft .NET Framework et Microsoft Office peuvent aider à protéger vos solutions Office contre des atteintes possibles à la sécurité. Cette rubrique décrit certaines de ces menaces et fournit des recommandations de protection. Elle présente également l'impact des paramètres de sécurité Microsoft Office sur les solutions Office.

S'applique à : Les informations contenues dans cette rubrique s'appliquent aux projets de niveau document et de niveau application pour Microsoft Office 2010 et la version 2007 de Microsoft® Office System. Pour plus d'informations, consultez Fonctionnalités disponibles par type d'application et de projet Office.

Un code de confiance est modifié à des fins malveillantes dans un nouveau document

Un agresseur peut prendre du code de confiance qui est destiné à un usage particulier (par exemple, le téléchargement d'informations personnelles pour postuler à un emploi) et le réutiliser dans un autre document (tel qu'une feuille de calcul). Le code ne sait pas que le document d'origine n'est pas en cours d'exécution, et peut ouvrir la voie à d'autres menaces (telles que la révélation d'informations personnelles ou l'exécution de code avec des privilèges accrus) lorsqu'il est ouvert par un autre utilisateur. L'agresseur peut aussi simplement modifier les données contenues dans la feuille de calcul de sorte qu'elle se comporte de manière inattendue lorsqu'elle est envoyée à la victime. En modifiant les valeurs, formules ou caractéristiques de présentation d'une feuille de calcul liée à du code, un utilisateur malveillant a la possibilité d'attaquer un autre utilisateur en envoyant un fichier modifié. Des utilisateurs peuvent également accéder à des informations qu'ils ne sont pas supposés voir en modifiant des valeurs de la feuille de calcul.

Étant donné que l'emplacement de l'assembly et l'emplacement du document doivent tous les deux disposer des preuves suffisantes pour s'exécuter, cette attaque n'est pas simple à mettre en œuvre. Par exemple, les documents contenus dans des pièces jointes de messages électroniques ou sur des serveurs intranet non fiables ne disposent pas des autorisations nécessaires pour s'exécuter.
Pour que cette attaque soit possible, le code lui-même doit être écrit de telle sorte qu'il prenne des décisions basées sur des données potentiellement non fiables. Dans cet exemple, une feuille de calcul est créée ; elle contient une cellule masquée dans laquelle se trouve le nom d'un serveur de base de données. L'utilisateur soumet la feuille de calcul à une page ASPX qui tente de se connecter à ce serveur à l'aide de l'authentification SQL et d'un mot de passe SA codé en dur. Un intrus pourrait remplacer le contenu de la cellule masquée par le nom d'un autre ordinateur et ainsi obtenir le mot de passe SA. Pour éviter ce problème, ne codez jamais en dur les mots de passe et vérifiez toujours que les ID de serveur figurent dans une liste interne de serveurs reconnus comme fiables avant d'accéder au serveur.

Recommandations

Validez toujours les données, qu'elles proviennent de l'utilisateur, du document, d'une base de données, d'un service Web ou de toute autre source.
Soyez très prudent lorsqu'il s'agit d'exposer des types particuliers de fonctionnalités, telles que l'obtention de données privilégiées pour le compte de l'utilisateur et leur placement dans une feuille de calcul non protégée.
En fonction du type d'application, il peut s'avérer utile de vérifier que le document d'origine est en cours d'exécution avant d'exécuter tout code (par exemple, en s'assurant que ce dernier est exécuté à partir d'un document stocké dans un emplacement connu et sécurisé).
Il peut être judicieux d'afficher un avertissement à l'ouverture du document si votre application effectue des actions privilégiées. Par exemple, vous pouvez créer un écran de démarrage ou une boîte de dialogue de démarrage indiquant que l'application va accéder à des informations personnelles, et demander à l'utilisateur s'il souhaite continuer ou annuler l'opération. Si un utilisateur final obtient un avertissement de ce type à partir d'un document en apparence innocent, il pourra quitter l'application avant que quoi que ce soit n'ait été mis en péril.

Le code est bloqué par le module de protection du modèle objet Outlook

Microsoft Office peut empêcher le code d'utiliser certaines propriétés et méthodes, et certains objets dans le modèle objet. En restreignant l'accès à ces objets, Outlook permet d'empêcher des vers informatiques de messagerie électronique et des virus d'utiliser le modèle objet dans un but malveillant. Cette fonctionnalité de sécurité est appelée « module de protection du modèle objet Outlook ». Si un complément tente d'utiliser une propriété ou une méthode restreinte alors que le module de protection du modèle objet est activé, Outlook affiche un avertissement de sécurité qui permet à l'utilisateur d'arrêter l'opération ou d'accorder l'accès à la propriété ou la méthode pour une période limitée. Si l'utilisateur arrête l'opération, les compléments Outlook créés à l'aide de Visual Studio Tools pour Office lèvent une COMException.

Le module de protection du modèle objet peut affecter des compléments de différentes façons, selon qu'Outlook est utilisé avec ou sans Microsoft Exchange Server :

Si Outlook n'est pas utilisé avec Exchange, un administrateur peut activer ou désactiver le module de protection du modèle objet pour tous les compléments sur l'ordinateur.
Si Outlook est utilisé avec Exchange, un administrateur peut activer ou désactiver le module de protection du modèle objet pour tous les compléments sur l'ordinateur ou spécifier que certains compléments peuvent s'exécuter sans que le module de protection du modèle objet n'intervienne. Les administrateurs peuvent également modifier le comportement du module de protection du modèle objet pour certaines zones du modèle objet. Par exemple, les administrateurs peuvent permettre automatiquement aux compléments d'envoyer des messages électroniques par programmation, même si le module de protection du modèle objet est activé.

Outlook 2007 modifie le comportement du module de protection du modèle objet afin d'améliorer l'expérience du développeur et de l'utilisateur tout en sécurisant Outlook. Pour plus d'informations, consultez Modifications de sécurité du code dans Outlook 2007 (page éventuellement en anglais).

Réduction au minimum des avertissements du module de protection du modèle objet

Pour éviter les avertissements de sécurité lorsque vous utilisez des propriétés et des méthodes restreintes, assurez-vous que votre complément obtient des objets Outlook du champ Application de la classe ThisAddIn de votre projet. Pour plus d'informations sur ce champ, consultez Programmation de compléments d'application.

Seuls les objets Outlook obtenus à partir de cet objet peuvent être approuvés par le module de protection du modèle objet. En revanche, les objets obtenus à partir d'un nouvel objet Microsoft.Office.Interop.Outlook.Application ne sont pas approuvés. Les propriétés et les méthodes restreintes déclencheront des avertissements de sécurité si le module de protection du modèle objet est activé.

L'exemple de code suivant affiche un avertissement de sécurité si le module de protection du modèle objet est activé. La propriété To de la classe Microsoft.Office.Interop.Outlook.MailItem est restreinte par le module de protection du modèle objet. L'objet Microsoft.Office.Interop.Outlook.MailItem n'est pas approuvé car le code l'obtient à partir d'une Microsoft.Office.Interop.Outlook.Application créée à l'aide de l'opérateur new au lieu de l'obtenir à partir du champ Application.

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

L'exemple de code suivant montre comment utiliser la propriété To restreinte d'un objet Microsoft.Office.Interop.Outlook.MailItem approuvé par le module de protection du modèle objet. Le code utilise le champ Application approuvé pour obtenir l'objet Microsoft.Office.Interop.Outlook.MailItem.

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

Notes

Si Outlook est utilisé avec Exchange, l'obtention de tous les objets Outlook à partir de ThisAddIn.Application ne garantit pas que votre complément pourra accéder au modèle objet Outlook entier. Par exemple, si un administrateur Exchange configure Outlook pour qu'il refuse automatiquement toutes les tentatives d'accès aux informations d'adresse à l'aide du modèle objet Outlook, Outlook ne permettra pas à l'exemple de code précédent d'accéder à la propriété To, bien qu'il utilise le champ ThisAddIn.Application approuvé.

Spécification des compléments à approuver lors de l'utilisation d'Exchange

Lorsque Outlook est utilisé avec Exchange, les administrateurs peuvent spécifier que certains compléments peuvent s'exécuter sans rencontrer le module de protection du modèle objet. Les compléments Outlook créés à l'aide de Visual Studio Tools pour Office ne peuvent pas être approuvés individuellement. Ils doivent faire l'objet d'une approbation de groupe.

Outlook approuve un complément en fonction d'un code de hachage de la DLL de point d'entrée du complément. Tous les compléments Outlook ciblant Visual Studio Tools pour Office Runtime utilisent la même DLL de point d'entrée (VSTOLoader.dll). Cela signifie que si un administrateur approuve l'exécution d'un complément ciblant Visual Studio Tools pour Office Runtime et estime donc que le module de protection du modèle objet n'est pas nécessaire, tous les autres compléments ciblant Visual Studio Tools pour Office Runtime seront également approuvés. Pour plus d'informations sur l'approbation d'exécution de compléments spécifiques sans rencontrer le module de protection du modèle objet, consultez Spécifier la méthode utilisée par Outlook pour gérer les fonctionnalités de prévention contre les virus (page éventuellement en anglais).

Les modifications apportées aux autorisations ne prennent pas effet immédiatement

Si l'administrateur ajuste les autorisations d'un document ou d'un assembly, ces modifications ne seront prises en compte que lorsque les utilisateurs auront quitté et redémarré toutes les applications Office.

D'autres applications qui hébergent des applications Microsoft Office peuvent également empêcher la prise en compte des nouvelles autorisations. En cas de modification des stratégies de sécurité, les utilisateurs doivent quitter toutes les applications qui utilisent Office, qu'elles soient hébergées ou autonomes.

Les paramètres du Centre de gestion de la confidentialité dans Microsoft Office System n'affectent ni les compléments ni les personnalisations au niveau du document

Les utilisateurs peuvent empêcher le chargement des compléments en définissant une option dans le Centre de gestion de la confidentialité. Toutefois, ces paramètres d'approbation n'affectent pas les compléments au niveau de l'application et les personnalisations au niveau du document créés à l'aide de Visual Studio Tools pour Office.

Si l'utilisateur empêche le chargement des compléments en utilisant le Centre de gestion de la confidentialité, le chargement des types de compléments suivants n'est pas effectué :

les compléments COM managés et non managés ;
les balises actives managées et non managées ;
les documents dynamiques managés et non managés ;
les compléments Automation managés et non managés ;
les composants de données en temps réel managés et non managés.

Notes

Les balises actives sont déconseillées dans Excel 2010 et Word 2010. Pour plus d'informations, consultez Vue d'ensemble des balises actives.

Les procédures suivantes décrivent la manière dont les utilisateurs peuvent utiliser le Centre de gestion de la confidentialité pour empêcher le chargement des compléments dans la version 2007 de Microsoft Office System. Ces procédures n'affectent pas les compléments ou personnalisations créés à l'aide de Visual Studio Tools pour Office.

Pour désactiver les compléments dans les applications Microsoft Office 2010, Excel 2007, PowerPoint 2007 ou Word 2007

Cliquez sur l'onglet Fichier (pour les applications Microsoft Office 2010) ou le bouton Microsoft Office (pour les applications de la version 2007 de Microsoft Office System).
Cliquez sur le bouton Options de NomApplication.
Dans le volet des catégories, cliquez sur Centre de gestion de la confidentialité.
Dans le volet d'informations, cliquez sur Paramètres du Centre de gestion de la confidentialité.
Dans le volet des catégories, cliquez sur Compléments.
Dans le volet d'informations, sélectionnez Exiger la signature des compléments d'applications par un éditeur approuvé ou Désactiver tous les compléments d'applications.

Pour désactiver les compléments dans InfoPath 2007, Outlook 2007, Project 2007 ou Visio 2007

Dans le menu Outils, cliquez sur Centre de gestion de la confidentialité.
Dans le volet des catégories, cliquez sur Sécurité des macros.
Dans le volet d'informations, sélectionnez Aucun avertissement et désactiver toutes les macros ou Avertissements pour les macros signées. Toutes les macros non signées sont désactivées.
Dans le volet des catégories, cliquez sur Compléments.
Dans le volet d'informations, sélectionnez Appliquer les paramètres de sécurité des macros aux compléments installés.

Voir aussi

Autres ressources

Sécurisation des solutions Office

Partager via