Um rastreamento de pilha deve estar na mensagem de erro apresentada ao usuário?

Eu costumo construir um log de aplicativo, seja no banco de dados ou no arquivo, e registrar todas essas informações para isso. Você pode então fornecer ao usuário um número de erro, que identifica com qual item de log o erro está relacionado, para que você possa recuperá-lo. Esse padrão também é útil, já que você pode acompanhar os erros mesmo que os usuários não se incomodem em criá-los com você, para que você possa ter uma ideia melhor de onde estão os problemas.

Se o seu site estiver instalado no ambiente de um cliente e você não puder alcançá-lo, você poderá obter o departamento de TI no local para enviar um extrato com base no erro nº.

A outra coisa que você pode considerar é fazer com que o sistema envie por e-mail detalhes de erros para uma caixa de correio que você tenha visto, para saber quando as coisas estão dando errado.

Fundamentalmente, ter um sistema que solta sua coragem quando algo não está certo não inspira confiança em usuários não-técnicos - isso tende a assustá-los e faze-los pensar que algo está errado (por exemplo, quanto de BSOD você entende, e como você se sente quando surge?

No stacktrace:

No .Net, o rastreio de pilha mostrará o rastreio completo diretamente nos principais conjuntos MS-sourced e revelará detalhes sobre quais tecnologias você está usando e as possíveis versões também. Isso dá aos intrusos informações valiosas sobre possíveis pontos fracos que podem ser explorados.

Sim, existem muitos.

Um rastreamento de pilha pode revelar

• qual algoritmo de criptografia você usa
• o que alguns caminhos existentes em seu servidor de aplicativos são
• se você está adequadamente sanitizando a entrada ou não
• como seus objetos são referenciados internamente
• qual versão e marca do banco de dados está por trás do seu front-end

... a lista continua e continua. Basicamente, todas as decisões de projeto em um aplicativo grande podem ser relevantes para a segurança, e quase todas elas podem ser fornecidas através de nomes de método ou módulo. Lembre-se, isso não significa que ainda não faz sentido exibir um rastreamento de pilha se o ambiente ao qual ele é submetido for seguro (por exemplo, uma intranet em vez de um site voltado para a Internet), mas o custo em segurança não é zero .

O problema é que não é nosso principal trabalho facilitar as coisas para nós mesmos. Nosso trabalho é facilitar as coisas para o usuário final. Para nós, um rastreamento de pilha parece uma informação extremamente útil para fornecer um desenvolvedor. Para um usuário, parece um conteúdo sem sentido que não serve para nada. Mesmo se você disser o contrário, eles não o internalizam. Se você acha difícil obter essas informações dos administradores do sistema, obtê-las dos usuários finais é ainda pior.

No que diz respeito à segurança, você pode ter razão se for um aplicativo de desktop. Nesse caso, a impressão de um rastreamento de pilha não fornece nada que um invasor ainda não saiba. Em um aplicativo da Web, essas informações ainda não estão disponíveis para um invasor. Você está, de fato, expondo detalhes internos que tornarão um ataque muito mais fácil.

Por que não ignorar as duas fontes de preocupação e receber relatórios de exceções enviados automaticamente para você? Dessa forma, você nem precisa se preocupar com as pessoas que não relatam erros.

Dê uma olhada em esta questão da Segurança de TI SE . Em resumo, um rastreamento de pilha pode fornecer ao atacante mais informações para trabalhar. Quanto mais informações o invasor tiver, maior a probabilidade de penetrar no sistema. Eu não basearia minha segurança no fato de que os rastreamentos de pilha estão sempre ocultos, mas isso também não significa que você deva fornecer essa informação aos invasores.

Você pode obter a maioria dos benefícios do registro de back-end adequado de qualquer maneira. É um pouco menos conveniente, mas provavelmente não vale a pena arriscar a segurança do seu sistema e incomodar seus clientes.

Você pode considerar não mostrar um rastreamento de pilha pelos seguintes motivos.

Segurança

Mostrar um rastreamento de pilha revela possíveis superfícies de ataque para serem hackers. Intranets não são imunes a hackers. Isso refletiria mal em você se sua rede foi invadida por causa de um aplicativo pelo qual você é responsável

Experiência do usuário

Para a melhor experiência do usuário, um rastreio de strack é muita informação. Sim, as informações adequadas sobre uma condição de erro devem ser registradas e receber atenção de um engenheiro. No entanto, exigir que um usuário faça o que você pode automatizar não será o melhor para o usuário.

Sua Reputação

Sempre que um rastreamento de pilha é exibido em um site, parece ruim. A maioria das pessoas não tem ideia do que é e isso faz com que eles sintam que o site não é amigável para eles. Para aqueles que sabem o que é, pode ser uma indicação de que o aplicativo não foi bem pensado. Muitos aplicativos mal escritos mostram rastreamentos de pilha com muita frequência porque é o padrão em alguns frameworks como ASP.Net.

Resposta curta: Em uma extranet ou site da Internet, faz sentido não mostrar o stacktrace. Em uma intranet, os benefícios de mostrar o stacktrace superam os de ocultá-lo.

Resposta longa:

O mesmo aconteceu comigo no trabalho. Eu costumava pensar que, se um aplicativo falha, ele deve falhar ruidosamente.

Mas então eles me explicaram que um hacker em potencial poderia inferir muitas coisas de um stacktrace.

Eu acho que não há necessidade de provas. É evidente que quanto mais um hacker sabe sobre sua plataforma, melhor para ele e quanto menos um hacker sabe sobre sua plataforma, melhor para você.

As empresas também não estão dispostas a divulgar como um hacker invadiu seus sistemas.

Por outro lado, é uma intranet , e eu acho que as vantagens de saber de imediato o que deu errado sem precisar pesquisar um arquivo de log é de grande vantagem e os riscos de segurança de mostrar um stacktrace dentro dos limites de sua empresa não são tão altos quanto eles estão dizendo.

Em qualquer produto entregue, o número esperado desse tipo de erro deve ser zero. A utilidade desta informação para o cliente é zero. Em ambos os casos, não há motivo para apresentar um rastreamento de pilha. Se houver algum contexto útil, ele deve ser apresentado de maneira amigável ao cliente, não como um rastreamento de pilha.

Por outro lado, se o número real de ocorrências não for zero, você precisa desesperadamente dessas informações e não deve depender do cliente para enviá-las a você. 99,99% do tempo eles não vão. Você deve instalar um sistema de relatórios de erros que submete as informações automaticamente, com apenas um "ok" do cliente.