Considérations de sécurité supplémentaires dans Windows Forms
Les paramètres de sécurité .NET Framework peuvent entraîner l’exécution de votre application différemment dans un environnement d’approbation partielle que sur votre ordinateur local. Le .NET Framework limite l’accès à des ressources locales critiques telles que le système de fichiers, le réseau et les API non managées, entre autres. Les paramètres de sécurité affectent la possibilité d’appeler l’API Microsoft Windows ou d’autres API qui ne peuvent pas être vérifiées par le système de sécurité. La sécurité affecte également d’autres aspects de votre application, notamment l’accès aux fichiers et aux données et l’impression. Pour plus d’informations sur l’accès aux fichiers et aux données dans un environnement d’approbation partielle, consultez Accès plus sécurisé aux fichiers et aux données dans windows Forms. Pour plus d’informations sur l’impression dans un environnement d’approbation partielle, consultez Impression plus sécurisée dans windows Forms.
Les sections suivantes expliquent comment utiliser le Presse-papiers, effectuer une manipulation de fenêtre et appeler l’API Windows à partir d’applications qui s’exécutent dans un environnement d’approbation partielle.
Accès au Presse-papiers
La classe UIPermission contrôle l’accès au Presse-papiers, et la valeur d’énumération UIPermissionClipboard associée indique le niveau d’accès. Le tableau suivant présente les niveaux d’autorisation possibles.
Valeur de la UIPermissionClipboard | Description |
---|---|
AllClipboard | Le Presse-papiers peut être utilisé sans restriction. |
OwnClipboard | Le Presse-papiers peut être utilisé avec certaines restrictions. La possibilité de placer des données dans le Presse-papiers (opérations de commande copier ou couper) est illimitée. Les contrôles intrinsèques qui acceptent le collage, comme une zone de texte, peuvent accepter les données du Presse-papiers, mais les contrôles utilisateur ne peuvent pas lire par programmation à partir du Presse-papiers. |
NoClipboard | Impossible d’utiliser le Presse-papiers. |
Par défaut, la zone Intranet local reçoit AllClipboard'accès et la zone Internet reçoit OwnClipboard'accès. Cela signifie que l’application peut copier des données dans le Presse-papiers, mais l’application ne peut pas coller ou lire par programmation à partir du Presse-papiers. Ces restrictions empêchent les programmes sans confiance totale de lire le contenu copié dans le Presse-papiers par une autre application. Si votre application nécessite un accès complet au Presse-papiers, mais que vous n’avez pas les autorisations nécessaires, vous devrez élever les autorisations pour votre application. Pour plus d’informations sur l'augmentation des permissions, consultez Administration générale de la stratégie de sécurité.
Manipulation de fenêtre
La classe UIPermission contrôle également l’autorisation d’effectuer une manipulation de fenêtre et d’autres actions liées à l’interface utilisateur, et la valeur d’énumération UIPermissionWindow associée indique le niveau d’accès. Le tableau suivant présente les niveaux d’autorisation possibles.
Par défaut, la zone Intranet local reçoit AllWindows'accès et la zone Internet reçoit SafeTopLevelWindows'accès. Cela signifie que dans la zone Internet, l’application peut effectuer la plupart des actions de fenêtrage et d’interface utilisateur, mais l’apparence de la fenêtre sera modifiée. La fenêtre modifiée affiche une notification de bulle lors de la première exécution, contient le texte de la barre de titre modifiée et nécessite un bouton fermer sur la barre de titre. La notification de bulle et la barre de titre indiquent à l'utilisateur que l'application s'exécute avec des autorisations partielles.
Valeur UIPermissionWindow | Description |
---|---|
AllWindows | Les utilisateurs peuvent utiliser sans restriction toutes les fenêtres et tous les événements de saisie utilisateur. |
SafeTopLevelWindows | Les utilisateurs peuvent utiliser uniquement des fenêtres de niveau supérieur et des sous-fenêtres de niveau supérieur plus sûrs pour le dessin, et peuvent utiliser uniquement des événements d’entrée utilisateur pour l’interface utilisateur dans ces fenêtres de niveau supérieur et sous-fenêtres de niveau supérieur. Ces fenêtres plus sûres sont clairement étiquetées et ont des restrictions de taille minimale et maximale. Les restrictions empêchent les attaques d’usurpation potentiellement dangereuses, telles que l’imitation des écrans d’ouverture de session système ou le bureau système, et limitent l’accès par programmation aux fenêtres parentes, aux API liées au focus et à l’utilisation du contrôle ToolTip, |
SafeSubWindows | Les utilisateurs peuvent utiliser uniquement des sous-fenêtres plus sûres pour le dessin et peuvent utiliser uniquement les événements d’entrée utilisateur pour l’interface utilisateur dans ce sous-menu. Un contrôle affiché dans un navigateur est un exemple de sous-menu plus sûr. |
NoWindows | Les utilisateurs ne peuvent pas utiliser d’événements windows ou d’interface utilisateur. Aucune interface utilisateur ne peut être utilisée. |
Chaque niveau d’autorisation identifié par l’énumération UIPermissionWindow autorise moins d’actions que le niveau supérieur à celui-ci. Les tableaux suivants indiquent les actions qui sont limitées par les valeurs SafeTopLevelWindows et SafeSubWindows. Pour obtenir des autorisations exactes requises pour chaque membre, consultez la référence de ce membre dans la documentation de la bibliothèque de classes .NET Framework.
Les autorisations SafeTopLevelWindows restreignent les actions répertoriées dans le tableau suivant.
Composant | Actions restreintes |
---|---|
Application | - Définition de la propriété SafeTopLevelCaptionFormat. |
Control | - Obtention de la propriété Parent. - Définition de la propriété Region .- Appel de la méthode FindForm, Focus, FromChildHandle et FromHandle, PreProcessMessage, ReflectMessageou SetTopLevel. - Appel de la méthode GetChildAtPoint si le contrôle retourné n’est pas un enfant du contrôle appelant. - Modifier le focus de contrôle à l’intérieur d’un contrôle conteneur. |
Cursor | - Définition de la propriété Clip. - Appel de la méthode Hide. |
DataGrid | - Appel de la méthode ProcessTabKey. |
Form | - Obtention de la propriété ActiveForm ou MdiParent. - Définition de la propriété ControlBox, ShowInTaskbarou TopMost. - Définir la propriété Opacity à une valeur inférieure à 50%. - Réglage de la propriété WindowState à Minimized par programme. - Appel de la méthode Activate. - Utilisation des valeurs d’énumération None, FixedToolWindowet SizableToolWindowFormBorderStyle. |
NotifyIcon | - L’utilisation du composant NotifyIcon est complètement restreinte. |
La valeur SafeSubWindows limite les actions répertoriées dans le tableau suivant, en plus des restrictions placées par la valeur SafeTopLevelWindows.
Composant | Actions restreintes |
---|---|
CommonDialog | - Affichage d’une boîte de dialogue dérivée de la classe CommonDialog. |
Control | - Appel de la méthode CreateGraphics. - Définition de la propriété Cursor. |
Cursor | - Définition de la propriété Current. |
MessageBox | - Appel de la méthode Show. |
Hébergement de contrôles tiers
Une autre manipulation de fenêtre peut se produire si vos formulaires hébergent des contrôles tiers. Un contrôle tiers est un UserControl personnalisé que vous n’avez pas développé et compilé vous-même. Bien que le scénario d’hébergement soit difficile à exploiter, il est théoriquement possible pour un contrôle tiers d’étendre sa surface de rendu pour couvrir toute la zone de votre formulaire. Ce contrôle peut ensuite imiter une boîte de dialogue critique et demander des informations telles que des combinaisons nom d’utilisateur/mot de passe ou des numéros de compte bancaire de vos utilisateurs.
Pour limiter ce risque potentiel, utilisez des contrôles tiers uniquement des fournisseurs que vous pouvez approuver. Si vous utilisez des contrôles tiers que vous avez téléchargés à partir d’une source non vérifiable, nous vous recommandons de passer en revue le code source pour les attaques potentielles. Une fois que vous avez vérifié que la source n’est pas malveillante, vous devriez compiler l’assembly vous-même pour garantir que la source correspond bien à l'assembly.
Appels d’API Windows
Si votre conception d’application nécessite l’appel d’une fonction à partir de l’API Windows, vous accédez au code non managé. Dans ce cas, les actions du code sur la fenêtre ou le système d’exploitation ne peuvent pas être déterminées lorsque vous utilisez des appels ou des valeurs d’API Windows. La classe SecurityPermission et la valeur UnmanagedCode de l'énumération SecurityPermissionFlag contrôlent l'accès au code non managé. Une application peut accéder au code non managé uniquement lorsqu’elle reçoit l’autorisation UnmanagedCode. Par défaut, seules les applications qui s’exécutent localement peuvent appeler du code non managé.
Certains membres de Windows Forms fournissent un accès non géré qui nécessite l'autorisation UnmanagedCode. Le tableau suivant répertorie les membres de l’espace de noms System.Windows.Forms qui nécessitent l’autorisation. Pour plus d’informations sur les autorisations requises pour un membre, consultez la documentation de la bibliothèque de classes .NET Framework.
Composant | Membre |
---|---|
Application | méthode - AddMessageFilter propriété - CurrentInputLanguage méthode - Exit méthode - ExitThread événement - ThreadException |
CommonDialog | méthode - HookProc méthode - OwnerWndProc\ méthode - Reset méthode - RunDialog |
Control | méthode - CreateParams méthode - DefWndProc méthode - DestroyHandle méthode - WndProc |
Help | - ShowHelp méthodes méthode - ShowHelpIndex |
NativeWindow | classe - NativeWindow |
Screen | méthode - FromHandle |
SendKeys | méthode - Send méthode - SendWait |
Si votre application n’a pas l’autorisation d’appeler du code non managé, votre application doit demander UnmanagedCode autorisation, ou vous devez envisager d’autres façons d’implémenter des fonctionnalités ; Dans de nombreux cas, Windows Forms fournit une alternative managée aux fonctions d’API Windows. Si aucune autre méthode n’existe et que l’application doit accéder au code non managé, vous devez élever les autorisations pour l’application.
L’autorisation d’appeler du code non managé permet à une application d’effectuer la plupart des opérations. Par conséquent, l’autorisation d’appeler du code non managé ne doit être accordée qu’aux applications provenant d’une source approuvée. En fonction de l’application, l’élément de fonctionnalité d’application qui effectue l’appel au code non managé peut être facultatif ou activé uniquement dans l’environnement de confiance totale. Pour plus d’informations sur les autorisations dangereuses, consultez Autorisations dangereuses et administration de stratégie. Pour plus d’informations sur l’élévation des autorisations, consultez Administration générale de la politique de sécurité.
Voir aussi
.NET Desktop feedback