O modo de depuração do ASP.NET é um risco de segurança?

Question

Desativar o modo de depuração no ASP.NET é uma das coisas mencionadas até nos tutoriais mais iniciantes sobre segurança do ASP.NET. Infelizmente, em projetos de sites, o modo de depuração é a única maneira de obter números de linha com registros de exceção: você não pode apenas ativar os PDBs enquanto deixa o site no modo de versão.

Os números de linha nos rastreamentos de pilha são excepcionalmente úteis para descobrir a causa das exceções de uma vez em uma lua azul que ocorrem apenas na produção.

Nosso servidor usa manipuladores de erro personalizados e o rastreamento está desativado. Existem outras maneiras de o modo de depuração ser prejudicial à segurança?

    

Answer 1

A liberação de PDBs permite a engenharia reversa do código-fonte de seus programas. Eu imagino que para a sua configuração você teria o código compilado em execução em um servidor que você possui e protege. Além disso, as informações de rastreamento de pilha seriam protegidas pela segurança do seu servidor de banco de dados.

O problema de segurança vem de um raciocínio semelhante para hashing de senhas. Se um invasor puder acessar seu banco de dados ou servidor, será mais fácil roubar informações confidenciais em seu código-fonte.

É tudo uma questão de seu apetite pelo risco. Se esta é apenas uma página inicial sem código sensível, então você pode aceitar o risco de vazamento de informações e roubo de código em vez de um tempo mais rápido de depuração / desenvolvimento. No entanto, se o inverso for verdadeiro, recomendo que você adote versões de produção e use um servidor de depuração fora de sua rede de produção para rastrear os problemas.

Além disso, usar um sistema de log como o nlog também pode ser uma boa solução para detectar problemas sem precisar liberar os PDBs. Você precisará escrever código de log suficiente para cobrir todas as suas bases, mas o esforço pode valer a pena se liberar PDBs é muito arriscado.