Compartilhar via


Segurança do Depurador

The ability to debug another process gives you extremely broad powers that you would not otherwise have, especially when debugging remotely. A malicious debugger could inflict widespread damage on the machine being debugged. Because of this, there are restrictions on who can do debugging. For more information, see Permissões de depuração remota.

However, many developers do not realize that the security threat can also flow in the opposite direction. É possível que código mal-intencionado do processo de depuração comprometa a segurança da máquina de depuração: Há um número de vulnerabilidades de segurança que devem ser protegidas.

Security Best Practices

There is an implicit trust relationship between the code you are debugging, and the debugger. If you are willing to debug something, you should also be willing to run it. The bottom line is that you must be able to trust what you are debugging. If you cannot trust it, then you should not debug it, or you should debug it from a machine that you can afford to jeopardize, and in an isolated environment.

In order to reduce the potential attack surface, debugging should be disabled on production machines. For the same reason, debugging should never be enabled indefinitely.

Managed Debugging Security

Here are some general recommendations that apply to all managed debugging.

For more information, see Depurando código gerenciado.

Remote Debugging Security

Local debugging is generally safer than remote debugging. Remote debugging increases the total surface area that can be probed.

The Visual Studio Remote Debugging Monitor (msvsmon.exe) is used in remote debugging, and there are several security recommendations for configuring it. The preferred way to configure the authentication mode is Windows Authentication, because No Authentication mode is insecure. When using Windows Authentication mode, be aware that granting an untrusted user permission to connect to msvsmon is dangerous, as will be indicated by a dialog box warning.

Não faça a depuração de um processo desconhecido em uma máquina remota: Existem possíveis explorações que podem afetar a máquina executando o depurador ou que pode comprometer msvsmon. exe, Visual Studio Remote Debugging Monitor. If you absolutely must debug an unknown process, try debugging locally, and use a firewall to keep any potential threats localized.

For more information, see Instalação de Depuração Remota.

Web Services Debugging Security

É mais seguro depurar localmente, mas desde então, você provavelmente não tem Visual Studio instalado no servidor web, depuração local pode não ser prático. Generally, debugging Web services is done remotely, except during development, so the recommendations for remote debugging security also apply to Web services debugging. Here are some additional best practices. For more information, see Debugging XML Web Services.

  • Do not enable debugging on a Web server that has been compromised.

  • Make sure you know the Web server is secure before debugging it. If you are not sure it is secure, do not debug it.

  • Be especially careful if you are debugging a Web service that is exposed on the Internet.

External Components

Be aware of the trust status of external components that your program interacts with, especially if you did not write the code. Também estar ciente de componentes que Visual Studio ou o depurador pode usar.

Symbols and Source Code

Dois Visual Studio Ferramentas que exigem preocupação de segurança são os seguintes:

Consulte também

Referência

Aviso de segurança: Anexar a um processo de um usuário não confiável pode ser perigoso. Se as seguintes informações parecerem suspeitas ou se você não tiver certeza, não se conectar a esse processo

Aviso de segurança: Depurador deve executar o comando não confiável

Outros recursos

Configurações e preparação para depuração

Guia para o depurador