Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Ce contenu s’applique uniquement au .NET Framework, sauf indication contraire.
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 Un 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 UIPermission classe contrôle l’accès au Presse-papiers, et la valeur d’énumération associée UIPermissionClipboard indique le niveau d’accès. Le tableau suivant présente les niveaux d’autorisation possibles.
| Valeur UIPermissionClipboard | Descriptif |
|---|---|
| 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 l’accès et la zone Internet reçoit OwnClipboard l’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 augmenter les droits d'accès pour votre application. Pour plus d’informations sur l’élévation des autorisations, consultez Administration générale des stratégies de sécurité.
Manipulation de fenêtre
La UIPermission classe 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 associée UIPermissionWindow 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 l’accès et la zone Internet reçoit SafeTopLevelWindows l’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 informent l'utilisateur que l'application est exécutée sous une confiance partielle.
| Valeur de UIPermissionWindow | Descriptif |
|---|---|
| AllWindows | Les utilisateurs peuvent utiliser toutes les fenêtres et tous les événements d’entrée utilisateur sans restriction. |
| 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 du système ou du bureau du système, et restreignent l'accès par programmation aux fenêtres parentes, aux API liées à la focalisation 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 restreintes 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.
SafeTopLevelWindows l’autorisation restreint les actions répertoriées dans le tableau suivant.
| Composant | Actions restreintes |
|---|---|
| Application | - Définition de la SafeTopLevelCaptionFormat propriété. |
| Control | - Obtention de la propriété Parent. - Définition de la Region propriété.- Appel des méthodes FindForm, Focus, FromChildHandle et FromHandle, PreProcessMessage, ReflectMessage ou SetTopLevel. - Appel de la GetChildAtPoint méthode 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 Clip propriété. - Appel de la Hide méthode. |
| DataGrid | - Appel de la ProcessTabKey méthode. |
| Form | - Obtention de la propriété ActiveForm ou MdiParent. - Définition de la propriété ControlBox, ShowInTaskbar ou TopMost. - Définir la Opacity propriété à moins de 50%. - Définition de la WindowState propriété Minimized par programmation. - Appel de la Activate méthode. - Utilisation des valeurs None, FixedToolWindow et SizableToolWindowFormBorderStyle d'énumération. |
| NotifyIcon | - L’utilisation du NotifyIcon composant est complètement restreinte. |
La SafeSubWindows valeur limite les actions répertoriées dans le tableau suivant, en plus des restrictions placées par la SafeTopLevelWindows valeur.
| Composant | Actions restreintes |
|---|---|
| CommonDialog | - Affichage d’une boîte de dialogue dérivée de la CommonDialog classe. |
| Control | - Appel de la CreateGraphics méthode. - Définition de la Cursor propriété. |
| Cursor | - Définition de la Current propriété. |
| MessageBox | - Appel de la Show méthode. |
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 tout contrôle personnalisé UserControl 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 devez compiler vous-même l'assemblage pour vous assurer que la source correspond à l'assemblage.
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 Windows Forms fournissent un accès non managé 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 |
-
AddMessageFilter méthode - CurrentInputLanguage propriété - Exit méthode- ExitThread méthode - ThreadException événement |
| CommonDialog |
-
HookProc méthode - OwnerWndProc\méthode - Reset méthode - RunDialog méthode |
| Control |
-
CreateParams méthode - DefWndProc méthode - DestroyHandle méthode - WndProc méthode |
| Help |
-
ShowHelp méthode - ShowHelpIndex méthode |
| NativeWindow | - NativeWindow classe |
| Screen | - FromHandle méthode |
| SendKeys |
-
Send méthode - SendWait méthode |
Si votre application n’a pas l’autorisation d’appeler du code non managé, votre application doit demander UnmanagedCode une 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 des stratégies. Pour plus d’informations sur l’élévation des autorisations, consultez Administration générale des stratégies de sécurité.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
.NET Desktop feedback