Sécurité du débogueur

La possibilité de déboguer un autre processus vous donne des pouvoirs extrêmement larges que vous n'auriez pas autrement, surtout lors du débogage à distance. Un débogueur malveillant pourrait infliger des dommages étendus sur l'ordinateur qui est débogué.

Toutefois, beaucoup de développeurs ne se rendent pas compte que la menace sur la sécurité peut également se dérouler dans le sens opposé. Il est possible pour le code malveillant dans le processus du programme débogué de compromettre la sécurité de l'ordinateur de débogage : il existe plusieurs exploits de sécurité dont il faut se garder.

Bonnes pratiques de sécurité

Il existe une relation de confiance implicite entre le code que vous déboguez et le débogueur. Si vous êtes disposé à déboguer quelque chose, vous devez également être disposé à l'exécuter. Au final, vous devez être en mesure d'avoir confiance en ce que vous déboguez. Si vous n'avez pas cette confiance, vous ne devez pas déboguer, ou vous devez déboguer le code à partir d'un ordinateur dont vous pouvez vous permettre de compromettre la sécurité, et dans un environnement isolé.

Pour réduire la surface d'attaque potentielle, le débogage doit être désactivé sur les ordinateurs de production. Pour la même raison, le débogage ne doit jamais être activé indéfiniment.

Sécurité de débogage managé

Voici quelques recommandations générales à appliquer à tout débogage managé.

• Soyez prudent lorsque vous rejoignez un processus utilisateur non fiable : dans ce cas, vous supposez qu'il est digne de confiance. Quand vous tentez d’attacher un processus d’un utilisateur non approuvé, une boîte de dialogue d’avertissement de sécurité s’affiche pour vous demander de confirmer l’attachement du processus. Vous faites partie des « utilisateurs approuvés », de même que les utilisateurs standard habituellement définis sur les machines où .NET Framework est installé, comme aspnet, localsystem, networkserviceet localservice. Pour plus d’informations, consultez avertissement de sécurité : l’attachement à un processus appartenant à un utilisateur non fiable peut être dangereux. Si les informations suivantes semblent suspectes ou si vous avez des doutes, n’attachez pas ce processus.

• Soyez prudent quand vous téléchargez un projet à partir d’Internet et que vous le charger dans Visual Studio. Il s'agit d'une opération très risquée sans débogage. Lorsque vous procédez ainsi, vous supposez que le projet et le code qu'il contient sont dignes de confiance.

  Pour plus d'informations, consultez Debugging Managed Code.

Sécurité du débogage à distance |

Le débogage local est généralement plus sûr que le débogage à distance. Le débogage distant augmente la zone de surface totale qui peut être sondée.

Visual Studio Remote Debugging Monitor (msvsmon.exe) est utilisé dans le débogage distant, et il existe plusieurs recommandations de sécurité pour le configurer. La façon par défaut de configurer le mode d'authentification est d'utiliser l'authentification Windows, parce que le mode Aucune Authentication n'est pas sécurisé.

Quand vous utilisez le mode Authentification Windows, n’oubliez pas qu’il est dangereux d’accorder une autorisation utilisateur non approuvée pour la connexion à msvsmon, car l’utilisateur reçoit toutes vos autorisations sur l’ordinateur qui héberge msvsmon.

Ne déboguez pas un processus inconnu sur une machine distante : il y a potentiellement du code malveillant exploitant une faille de sécurité qui peut affecter la machine exécutant le débogueur, ou cela peut compromettre msvsmon. Si vous devez absolument déboguer un processus inconnu, essayez de le déboguer localement et utilisez un pare-feu pour que toutes les menaces potentielles restent localisées.

Pour plus d’informations sur la configuration de msvsmon, consultez Configurer le débogueur distant.

Sécurité de débogage Web Services

Il est plus sûr de déboguer localement, mais puisque vous n’avez probablement pas Visual Studio installé sur le serveur web, le débogage local n’est peut-être pas pratique. En général, le débogage de services web s'effectue à distance, sauf pendant le développement, ce qui fait que les recommandations pour la sécurité de débogage distant s'appliquent également au débogage de services web. Voici quelques meilleures pratiques supplémentaires. Pour plus d'informations, consultez Debugging XML Web Services.

• N’activez pas le débogage sur un serveur web qui a été compromis.

• Assurez-vous que le serveur web est sécurisé avant de le déboguer. Si vous n'êtes pas sûr qu'il le soit, ne le déboguez pas.

• Soyez particulièrement prudent si vous déboguez un service web qui est exposé sur Internet.

Composants externes

Déterminez l'état de confiance des composants externes avec lesquels votre programme interagit, surtout si vous n'avez pas écrit le code. Déterminez également les composants que Visual Studio ou le débogueur peut utiliser.

Symboles et code source

Voici deux outils Visual Studio qui nécessitent une réflexion à propos de la sécurité :

• Le serveur source, qui fournit des versions de code source d'un référentiel de code source. Ceci est utile lorsque vous n'avez pas la version actuelle du code source d'un programme. Avertissement de sécurité : Le débogueur doit exécuter une commande non approuvée

• Le serveur de symboles, qui est utilisé pour fournir les symboles nécessaires pour déboguer un incident pendant un appel système.

  Consultez Spécifier les fichiers de symbole (.pdb) et les fichiers sources

Contenu connexe

• Paramètres et préparation du débogueur
• Présentation du débogueur
• Avertissement de sécurité : l’attachement à un processus appartenant à un utilisateur non approuvé peut être dangereux. Si les informations suivantes semblent suspectes ou si vous avez des doutes, ne faites pas d’attachement à ce processus
• Avertissement de sécurité : Le débogueur doit exécuter une commande non approuvée