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

Article
03/04/2013

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 Office 2013 et Office 2010. Pour en savoir plus, 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 code de confiance qui est signifié pour un usage spécial, par exemple, téléchargement de données personnelles pour une application d'instructions, 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 de exécution, et peut ouvrir d'autres menaces, telles que des informations personnelles de directive ou code de s'exécuter avec des privilèges augmentés, 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 l'entrée et les données, si elle provient 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.
Selon le type d'application, il peut s'avérer utile de vérifier que le document d'origine s'exécute avant d'exécuter tout code.Par exemple, vérifiez qu'il exécute d'un document stocké dans un emplacement sécurisé et.
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'exécution, les compléments Outlook créés à l'aide de solutions Office dans Visual Studio lève 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é.

À partir de Outlook 2007, le comportement du module de protection du modèle objet a été modifié pour améliorer l'expérience du développeur et de l'utilisateur tout en aidant à conserver Outlook sécurisé.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);
}

[!REMARQUE]

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 solutions Office dans Visual Studio ne peut pas être approuvés individuellement ; elles peuvent être faites confiance en tant que 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, les compléments au niveau de l'application et les personnalisations au niveau de le document créés à l'aide de solutions Office dans Visual Studio ne sont pas affectés par ces paramètres d'approbation.

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

Les procédures suivantes décrivent comment les utilisateurs peuvent utiliser Le Centre de gestion de la confidentialité pour restreindre les compléments du chargement dans Microsoft Office 2013 et Microsoft Office 2010.Ces procédures n'affectent pas les compléments ou personnalisations créées à l'aide de les Outils de développement Office dans Visual Studio.

Pour désactiver les compléments dans les applications Microsoft Office 2010 et Microsoft Office 2013

Choisissez Fichier tableau.
Choisissez le bouton de Nomapplication Options .
Dans le volet des catégories, cliquez sur Le Centre de gestion de la confidentialité.
Dans le volet d'informations, choisissez 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.

Voir aussi

Autres ressources

Sécurisation des solutions Office

Partager via