Partager via


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

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

Error dialog

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é :