Segurança do depurador

A capacidade de depurar outro processo dá-lhe poderes extremamente amplos que de outra forma não teria, especialmente ao depurar remotamente. Um depurador mal-intencionado pode infligir danos generalizados à máquina que está sendo depurada.

No entanto, muitos desenvolvedores não percebem que a ameaça à segurança também pode fluir na direção oposta. É possível que códigos maliciosos no processo de debug comprometam a segurança da máquina de depuração: há uma série de vulnerabilidades de segurança contra as quais é necessário proteger-se.

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 estiveres disposto a depurar algo, deves também estar disposto a executá-lo. A conclusão é que você deve ser capaz de confiar no que está depurando. Se você não pode confiar nele, então você não deve depurá-lo, ou você deve depurá-lo de uma máquina que você pode se dar ao luxo de colocar em risco, e em um ambiente isolado.

Para reduzir a superfície potencial de ataque, deve-se desativar a depuração nas máquinas de produção. Pela mesma razão, a depuração nunca deve ser ativada indefinidamente.

Segurança de depuração gerenciada

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

• Tenha cuidado ao conectar-se ao processo de um usuário não confiável: ao fazer isso, assume que ele é confiável. Quando você tenta anexar ao processo de um usuário não confiável, uma confirmação da caixa de diálogo de aviso de segurança será exibida perguntando se você deseja anexar ao processo. "Usuários confiáveis" incluem você e um conjunto de usuários padrão comumente definidos em máquinas que têm o .NET Framework instalado, como aspnet, localsystem, networkservice e localservice. Para obter mais informações, consulte Aviso de segurança: anexar a um processo de propriedade de um usuário não confiável pode ser perigoso. Se as seguintes informações parecerem suspeitas ou se não tiver a certeza, não anexe a este processo.

• Tenha cuidado ao baixar um projeto da Internet e carregá-lo no Visual Studio. É muito arriscado fazer isso, mesmo sem depuração. Ao fazer isso, você está assumindo que o projeto e o código que ele contém são confiáveis.

  Para obter mais informações, consulte 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 de superfície total que pode ser investigada.

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. A maneira preferida de configurar o modo de autenticação é a Autenticação do Windows, porque o modo Sem Autenticação é inseguro.

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

Não depure um processo desconhecido em uma máquina remota: há exploits potenciais que podem afetar a máquina que executa o depurador ou que podem comprometer o msvsmon. Se você absolutamente precisa depurar um processo desconhecido, tente depurar localmente e use um firewall para manter quaisquer ameaças potenciais localizadas.

Para obter informações sobre como configurar o 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 pode não ser prática. Geralmente, a depuração de serviços Web é feita remotamente, exceto durante o desenvolvimento, portanto, as recomendações para a segurança de depuração remota também se aplicam à depuração de serviços Web. Aqui estão algumas práticas recomendadas adicionais. Para obter mais informações, consulte Depuração de Serviços Web XML.

• Não ative a depuração num servidor web que tenha sido comprometido.

• Certifique-se de saber que o servidor Web é seguro antes de depurá-lo. Se você não tiver certeza de que é seguro, não o depure.

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

Componentes Externos

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

Símbolos e código-fonte

Duas ferramentas do Visual Studio que exigem pensar em segurança são as seguintes:

• Servidor de origem, que fornece versões do 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 de um programa. Aviso de segurança: O depurador deve executar um comando não confiável.

• Symbol Server, que é usado para fornecer os símbolos necessários para depurar uma falha durante uma chamada do sistema.

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

Conteúdo relacionado

• Configurações e preparação do depurador
• Introdução ao depurador
• Aviso de segurança: Anexar a um processo pertencente a um utilizador não confiável pode ser perigoso. Se as seguintes informações parecerem suspeitas ou se não tiver a certeza, não anexe a este processo
• Aviso de segurança: O depurador deve executar um comando não confiável