Segurança do depurador

A capacidade de depurar outro processo oferece poderes extremamente amplos que você não teria de outra forma, especialmente ao depurar remotamente. Um depurador mal-intencionado pode impor danos extensivos no computador que está sendo depurado.

Porém, muitos desenvolvedores não percebem que a ameaça à segurança também pode fluir na direção oposta. É possível que o código mal-intencionado no processo a ser depurado possa comprometer a segurança do computador de depuração: há várias explorações de segurança das quais você deve se proteger.

Práticas recomendadas de segurança

Há uma relação de confiança implícita entre o código que você está depurando e o depurador. Se você estiver disposto a depurar algo, também deverá estar disposto a executá-lo. Ou seja, você deve ser capaz de confiar no que está depurando. Se você não puder confiar, não deverá depurar, ou deverá depurar de um computador com recursos que possam ser comprometidos e em um ambiente isolado.

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

Segurança de depuração gerenciada

Aqui estão algumas recomendações gerais que se aplicam a todas as depurações gerenciadas.

• Tenha cuidado ao anexar ao processo de um usuário não confiável: quando você faz isso, pressupõe que ele seja confiável. Quando você tenta anexar a um processo de usuário não confiável, uma caixa de diálogo de confirmação de aviso de segurança será exibida perguntando se você deseja anexar ao processo. Os "usuários confiáveis" incluem você e um conjunto de usuários padrão, comumente definidos em computadores que tenham o .NET Framework instalado, por exemplo, aspnet, localsystem, networkservice e localservice. Para obter mais informações, consulte aviso de segurança: Anexar a um processo pertencente a um usuário não confiável pode ser perigoso. Se as informações a seguir parecerem suspeitas ou, se você não tiver certeza, não anexe a esse processo.

• Tenha cuidado ao baixar um projeto da Internet e carregá-lo no Visual Studio. Isso é muito arriscado de fazer mesmo sem depuração. Quando você fizer isso, estará supondo que o projeto e o código que contém sejam confiáveis.

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

Segurança de depuração remota

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

O Monitor de Depuração Remota do Visual Studio (msvsmon.exe) é usado na depuração remota e há várias recomendações de segurança para configurá-lo. O modo preferido de configurar o modo de autenticação é a autenticação do Windows, pois Modo Sem Autenticação não é seguro.

Ao usar o modo de Autenticação do Windows, observe que conceder a um usuário não confiável permissão para se conectar a msvsmon é perigoso, pois o usuário recebe todas as permissões no computador que hospeda msvsmon.

Não depure um processo desconhecido em um computador remoto: há explorações potenciais que podem afetar o computador que executa o depurador ou podem comprometer msvsmon. Se for absolutamente necessário depurar um processo desconhecido, tente depurá-lo localmente e use um firewall para manter todas as ameaças potenciais localizadas.

Para obter informações sobre como configurar msvsmon, consulte Configurar o depurador remoto.

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

É mais seguro depurar localmente, mas como você provavelmente não tem o Visual Studio instalado no servidor Web, a depuração local poderá não ser prática. Em geral, depurar serviços Web é feito remotamente, exceto durante o desenvolvimento, de modo que as recomendações para a segurança de depuração remota também se aplicarão à depuração de serviços Web. Aqui estão algumas práticas recomendadas adicionais. Para obter mais informações, consulte Depurando serviços Web XML.

• Não habilite a depuração em um servidor Web que tenha sido comprometido.

• Verifique se você sabe que o servidor Web está seguro antes de depurá-lo. Se você não tiver certeza se ele está seguro, não o depure.

• Tenha um cuidado especial se estiver depurando um serviço Web que está exposto na Internet.

Componentes externos

Conheça o status de confiança de componentes externos com os quais seu programa interage, especialmente se você não escreveu o código. Esteja ciente também dos componentes que o Visual Studio ou o depurador podem usar.

Símbolos e código-fonte

As duas ferramentas do Visual Studio que demandam preocupações com segurança são as seguintes:

• O Servidor de Origem, que fornece versões do código-fonte de um repositório de códigos-fonte. É útil quando você não tem a versão atual do código-fonte de um programa. Aviso de segurança: o depurador deve executar o comando não confiável

• O servidor do símbolo, que é usado para fornecer os símbolos necessárias para depurar uma falha durante uma chamada do sistema.

  Confira Especificar arquivos de símbolo (.pdb) e de origem

Conteúdo relacionado

• Preparação e configurações do depurador
• Introdução ao depurador
• Aviso de segurança: A anexação a um processo pertencente a um usuário não confiável pode ser perigosa. Se as informações a seguir parecerem suspeitas ou, se você não tiver certeza, não anexe a esse processo
• Aviso de segurança: o depurador deve executar o comando não confiável