Segurança do depurador

Artigo
02/25/2013

A capacidade de depurar um outro processo lhe poderes extremamente grandes que você não teria, especialmente quando estiver depurando remotamente.Um depurador mal-intencionado poderia inflingir danos amplos no computador que está sendo depurado.Dessa forma, há restrições sobre quem pode fazer a depuração.Para mais informações, consulte Remote Debugging Permissions.

No entanto, muitos desenvolvedores não percebem que a ameaça de segurança também pode fluir na direção oposta.É possível que código mal-intencionado no processo de depuração comprometa a segurança da máquina de depuração: há um número de explorações de segurança que devem ser protegidas.

Práticas recomendadas de segurança

Há uma relação de confiança implícito entre o código que você está depurando e o depurador.Se você estiver disposto a depurar algo, você também deve estar disposto a executá-lo.A linha inferior é que você deve ser capaz de confiar você está depurando.Se você não deve confiar nele, então você não deve depurar ou você deve depurar a partir de uma máquina que você pode comprometer e em um ambiente isolado.

Para reduzir a superfície de ataque potencial, a depuração deve ser desabilitada em computadores de produção.Pelo mesmo motivo, depuração nunca deve ser habilitada indefinidamente.

Segurança de depuração gerenciada

Aqui estão algumas recomendações gerais que se aplicam a toda depuração gerenciada.

Tenha cuidado ao anexar ao processo de usuário não confiável: quando você fizer isso, você assume que é confiável.Quando você tentar anexar ao processo de usuário não confiável, uma confirmação de caixa de diálogo de aviso de segurança aparecerá perguntando se você deseja anexar ao processo. "Usuários confiáveis"incluem você e um conjunto de usuários padrão normalmente definidos em computadores que têm o.NET Framework instalado, como aspnet, localsystem, networkservice, e localservice.Para mais informações, consulte Aviso de segurança: Anexação a processo pertencente a um usuário não confiável pode ser perigoso. Se as seguintes informações parecem suspeitas ou você não tiver certeza, não se conectar a esse processo.
Tenha cuidado ao fazer download de um projeto fora da Internet e carregá-lo em Visual Studio.Isso é muito arriscado fazer mesmo sem depuração.Quando você fizer isso, você está assumindo o projeto e o código que ele contém são confiáveis.

Para mais informações, consulte Depurando código gerenciado.

Segurança de depuração remota

Depuração local é geralmente mais segura do que a depuração remota.Depuração remota aumenta a área de superfície total pode ser analisada.

Visual Studio Remote Debugging Monitor (msvsmon. exe) é usado na depuração remota, e há várias recomendações de segurança para configurá-lo.A melhor maneira de configurar o modo de autenticação é a autenticação do Windows, porque o modo No Authentication é inseguro.

Diálogo de erro

Ao usar o modo de autenticação do Windows, esteja ciente que conceder uma permissão de usuário não confiável para se conectar ao msvsmon é perigoso, pois o usuário é concedido a todas as suas permissões no computador..

Não depure um processo desconhecido em um computador remoto: há possíveis vulnerabilidades que podem afetar a máquina executando o depurador ou que pode comprometer msvsmon. exe, Visual Studio Remote Debugging Monitor.Se você absolutamente deve depurar um processo desconhecido, tente depurar localmente e use um firewall para manter quaisquer ameaças em potencial localizadas.

Para mais informações, consulte Configuração de depuração remota.

Segurança de depuração de serviços da Web

É mais seguro depurar localmente, mas desde que você provavelmente não tem Visual Studio instalado no servidor web, depuração local pode não ser prático.Geralmente, a depuração de serviços da Web é feita remotamente, exceto durante o desenvolvimento, portanto as recomendações de segurança de depuração remota também se aplicam a depuração de serviços da Web.Aqui estão algumas recomendações adicionais.Para mais informações, consulte Debugging XML Web Services.

Não ative a depuração em um servidor Web que foi comprometido.
Verifique se que você sabe que o servidor Web é seguro antes de depurá-lo.Se não se é seguro, não faça a depuração.
Tome cuidado principalmente se você estiver depurando um serviço da Web que é exposto na Internet.

Componentes externos

Conhecer o status de confiança de componentes externos que o programa interage, especialmente se você não escreveu o código.Também estar ciente de componentes que Visual Studio ou pode usar o depurador.

Símbolos e código-fonte

Dois Visual Studio ferramentas que exigem pensar sobre segurança são os seguintes:

Servidor de origem, que lhe fornece versões de código fonte de um repositório de código fonte.É útil quando você não tem a versão atual do código-fonte do programa.Para obter mais informações, consulte [OBSOLETO] Como obter o código-fonte usando o servidor de origem e Aviso de segurança: O depurador deve executar o comando não confiável.
Servidor de símbolos, que é usado para fornecer os símbolos necessários para depurar uma falha durante uma chamada do sistema.Para obter mais informações, consulte [OBSOLETO] Como especificar locais de símbolos e o comportamento do carregamento e [OBSOLETE] Como usar um servidor de símbolo.