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

45

Eu tenho um pouco de discussão no meu local de trabalho e estou tentando descobrir quem está certo e qual é a coisa certa a fazer.

Contexto: um aplicativo da Web da intranet que nossos clientes usam para contabilidade e outros itens de ERP.

Sou da opinião de que uma mensagem de erro apresentada ao usuário (quando as coisas falham) deve incluir o máximo de informações possível, incluindo o rastreamento de pilha. Obviamente, ele deve começar com um belo "Ocorreu um erro, envie as informações abaixo para os desenvolvedores" em letras grandes e amigáveis.

Meu raciocínio é que uma captura de tela do aplicativo com falha geralmente será a única fonte de informações facilmente disponível. Claro, você pode tentar contatar o (s) administrador (es) de sistemas do cliente, tentar explicar onde estão seus arquivos de log, etc., mas isso provavelmente será lento e doloroso (conversar principalmente com os representantes do cliente).

Além disso, ter informações imediatas e completas é extremamente útil no desenvolvimento, onde você não precisa procurar nos arquivos de log para encontrar o que precisa em todas as exceções. (Mas isso pode ser resolvido com um comutador de configuração.)

Infelizmente, houve algum tipo de "auditoria de segurança" (não faço ideia de como eles fizeram isso sem as fontes ... mas tanto faz), e eles reclamaram das mensagens completas de exceção, citando-as como uma ameaça à segurança. Naturalmente, os clientes (pelo menos um que eu conheço) aceitaram isso pelo valor nominal e agora exigem que as mensagens sejam limpas.

Não vejo como um invasor em potencial poderia usar um rastreamento de pilha para descobrir algo que ele não poderia ter descoberto antes. Existem exemplos ou provas documentadas de alguém fazendo isso? Eu acho que devemos lutar contra essa ideia tola, mas talvez eu seja o tolo aqui, então ...

Quem está certo?

security error-handling

— Vilx-
fonte

25

Uau. Apenas Uau. " Unfortunately there has been some kind of "Security audit"" - Sério? Que tipo de atitude é essa? As auditorias de segurança são para seu benefício - para melhorar seus sistemas, para encontrar os problemas antes dos bandidos. Você realmente deve considerar tentar trabalhar com eles, não contra eles. Além disso, você pode tentar obter mais informações sobre o PoV de segurança em Information Security .

— AviD 23/08/12

7

E, por outro lado, uma auditoria de segurança não precisa necessariamente de acesso ao código-fonte; eles provavelmente fizeram um teste de penetração de caixa preta, simulando o que um usuário mal-intencionado faria - tente atacar o aplicativo como usuário. Embora eu concorde que o acesso ao código fonte possa ter permitido uma forma muito mais eficaz de auditoria. :-)

— AviD 23/08/2012

1

@AviD - na verdade, não sei o que eles analisaram, mas, a partir de alguns relatórios, vi que me pareceu um teste de caixa preta. Para ser sincero, não quero trabalhar contra eles. Na verdade, gostei das notícias quando as ouvi. Mas essa "vulnerabilidade" particular deles parece boba para mim. Em todas as decisões de segurança, é necessário ponderar a redução da ameaça contra a redução da usabilidade. Nesse caso, acho que reduz a usabilidade muito mais do que melhora a segurança.

— Vilx-

1

Concordo muito com a pesagem, mas discordo de sua aplicação. Isso prejudica a segurança mais do que você pensa, e eu também acho que seu jeito (tendo feito isso também, até falar com alguns usuários ...) é pior para a usabilidade. Pense nisso em termos orientados para tarefas - como a resposta de Jon disse, seu caminho faz com que o trabalho do usuário seja muito melhor. O usuário não precisa se preocupar com a pilha (a menos que seus usuários sejam os desenvolvedores ...) Mas, minha experiência é em segurança - e os riscos são reais.

— AviD 23/08/12

1

@AviD - Talvez você possa me indicar alguns recursos que explicam como um rastreamento de pilha pode ser perigoso? Estou pronto para aceitar isso, mas quero algo mais do que o princípio geral de "apenas mostrar o que você precisa".

— Vilx-

73

Costumo criar um log de aplicativo, no banco de dados ou no arquivo, e registrar todas essas informações para isso. Em seguida, você pode fornecer ao usuário um número de erro, que identifica a qual item de log o erro está relacionado, para que você possa recuperá-lo. Esse padrão também é útil, pois você pode seguir os erros, mesmo que os usuários não se preocupem em criá-los com você, para ter uma idéia melhor de onde estão os problemas.

Se o seu site estiver instalado no ambiente de um cliente e você não conseguir alcançá-lo, o departamento de TI no local enviará uma extração com base no erro não.

A outra coisa que você pode considerar é ter os detalhes de erros do sistema por e-mail em uma caixa de correio que você vê, para saber quando as coisas estão dando errado.

Fundamentalmente, ter um sistema que se destaca quando algo não está certo não inspira confiança em usuários não técnicos - tende a assustá-los a pensar que algo está muito errado (por exemplo, quanto de um BSOD você entende e como você sente quando alguém aparece)?

No stacktrace:

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

— Jon Egerton
fonte

6

Gosto da sua resposta porque apresenta um "caminho do meio" - não mostre, mas facilite a pesquisa de exceções. Vou tentar insistir nisso agora, espero que eles concordem. Obrigado!

— Vilx-

2

Eu acho que essa é praticamente a abordagem "madura" padrão. Além disso, o stacktrace fornece muitas informações, no entanto, ainda estou para encontrar uma solução que possa registrar automaticamente as informações de estado junto com o stacktrace (sem alterações de código em todos os lugares). Parece que escrever seu próprio depurador e anexá-lo é um caminho possível, mas longe de ser trivial de implementar.

— Daniel B

@DanielB: Nos aplicativos da Web, é possível obter algumas coisas comuns (como ID do usuário, ID do cliente etc.) da sessão / cache - como persiste "globalmente", mesmo essa quantidade de informações pode ajudar a reproduzir muito os erros. Mais granular do que isso é muito complicado, como você diz.

— 21812 Jon Egerton

2

Alguns usuários de aplicativos muito críticos exigem soluções imediatas para qualquer erro que impeça o curso normal dos negócios. Todo o processo de comunicação que envolve várias disciplinas apenas para o solucionador de erros obter a pilha de erros pode consumir facilmente 1 hora ou mais quando o erro ocorre tarde da noite ou nos fins de semana.

— Tulains Córdova

1

@ user1598390: Concordou, nesse caso, a cópia dos detalhes do erro em uma caixa de correio de suporte monitorada pode acelerar a coleta de informações, a ponto de a equipe de suporte saber que algo está quebrado mesmo antes do usuário.

— Jon Egerton

29

Sim, existem muitos.

Um rastreamento de pilha pode revelar

qual algoritmo de criptografia você usa
quais são os caminhos existentes no servidor de aplicativos
se você está limpando adequadamente 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 design em um aplicativo grande podem ser relevantes para a segurança e quase todas podem ser distribuídas por nomes de métodos ou módulos. Lembre-se, isso não significa que ainda não faz sentido exibir um rastreamento de pilha se o ambiente ao qual ele é submetido é seguro (por exemplo, uma intranet em vez de um site voltado para a Internet), mas o custo em segurança definitivamente não é zero .

— Kilian Foth
fonte

6

Eu concordo na maior parte, mas algumas dessas coisas não devem importar. Por exemplo, qual algoritmo de criptografia que você está usando não deve ser secreto para proteger seu sistema.

— Oleksi

3

Não deveria importar, mas o mundo é imperfeito, e muitas vezes importa. É por isso que a defesa em profundidade (fazendo muitas coisas simultaneamente que deveriam ser suficientes se fossem perfeitas) é importante.

— Kilian Foth

3

Francamente, se um rastreamento de pilha revelar algo que poderia ajudar um invasor, você está fazendo errado !

— Mark Booth

3

@ MarkBooth estatisticamente falando, você provavelmente está fazendo errado. Não, raspe isso - a certeza estatística de que você está entendendo errado. Deseja realmente permitir que os invasores encontrem seus bugs de segurança antes de você?

— AviD 23/08/12

1

@AviD - Não, eu concordo, o motivo mais convincente para não exibir rastreamentos de pilha para os usuários é que eles não têm idéia do que fazer com eles, e seu sistema de registro deve ser seguro e capaz de capturar muito mais estado do que uma captura de tela de uma página da web jamais poderia.

— Mark Booth

15

O problema é que não é nosso trabalho principal 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 uma bobagem completa 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 de 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, imprimir um rastreamento de pilha não fornece nada que um invasor ainda não saiba. Em um aplicativo Web, essas informações ainda não estão disponíveis para um invasor. Você está realmente expor detalhes internos que vão fazer um ataque a muito mais fácil.

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

— Karl Bielefeldt
fonte

2

Os usuários se beneficiam de uma solução rápida de seu problema, graças às informações fornecidas pelo rastreamento de pilha. Mas entendi o seu ponto.

— Tulains Córdova 23/08/2012

11

Dê uma olhada nesta questão do IT Security SE . Em resumo, um rastreamento de pilha pode fornecer ao invasor mais informações para trabalhar. Quanto mais informações o invasor tiver, maior será a probabilidade de elas invadirem seu 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ê deve fornecer essas informações aos invasores.

Você pode obter a maioria dos benefícios do log 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.

— Oleksi
fonte

8

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 que seriam hackers. As intranets não são imunes a hackers. Isso refletiria muito mal em você se sua rede fosse invadida por causa de um aplicativo pelo qual você é responsável

Experiência de usuário

Para a melhor experiência do usuário, um rastreamento 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, pedir a um usuário que 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 é mostrado em um site, ele fica ruim. A maioria das pessoas não tem idéia do que é e isso as faz sentir que o site não é amigável para elas. Para quem sabe o que é, pode ser uma indicação de que o aplicativo não foi bem pensado. Muitos aplicativos mal gravados mostram rastreamentos de pilha com muita frequência porque é o padrão em algumas estruturas como o ASP.Net.

— Tom Resing
fonte

6

Como desenvolvedor de software, quando vejo um rastreio de pilha na tela, meu pensamento imediato é "Aqui está um bozo que não sabe nada sobre como lidar com erros, se importa menos com eles e provavelmente com menos usuários". Outros giram em torno de "este é um software ruim, não funciona, seu tratamento de erros não funciona" e "WTF .... Eu não estou fazendo esse trabalho para ele" O que seu usuário quer saber é o que ele precisa fazer para consertar isso. Como o rastreamento de pilha faz isso.

— mattnz

6

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

Resposta longa:

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

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

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

Além disso, as empresas não desejam divulgar como um hacker invadiu seus sistemas.

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

— Tulains Córdova
fonte

1

quais são algumas das "vantagens de saber imediatamente o que deu errado" e por que elas não podem ser recuperadas de um arquivo de log? Parece que, com uma Intranet, você pode acessar um arquivo de log com mais facilidade do que em um site cliente.

— Wonko the Sane

No meu cenário, existem aplicativos críticos que têm prioridade "7/24". O suporte técnico da chamada do usuário, se o problema for um erro ou exceção de aplicativo, o suporte técnico liga para o mantenedor que talvez esteja fora do local. Com as informações de erro, o especialista pode instruir uma pessoa no local para uma solução alternativa ... Muitas vezes, o tempo economizado é precioso se o aplicativo for crítico para os negócios. se o especialista que, fora das premissas, tiver primeiro de se conectar à empresa, pesquisar no log etc., uma função crítica do negócio poderá estar esperando desnecessariamente.

— Tulains Córdova

3

@ user1598390 para criar um mecanismo de visualização de logs. Uma página da Web simples, insira o ID do incidente e o suporte técnico pode ver todo o registro relevante. É claro que limitar o acesso a este recurso, e assim por diante ...

— Avid

Só porque um aplicativo está na intranet da sua empresa, não significa que não haja usuários maliciosos nele. Existem muitos funcionários descontentes por aí que podem muito bem usar mal um sistema interno para seu próprio benefício. Como esses funcionários sabem muito sobre a empresa e suas políticas, eles podem ser mais perigosos do que um hacker interno. Passar por arquivos de log é uma tarefa bastante trivial, especialmente se você estiver seguindo boas práticas e também registrar erros em um arquivo de log de erros específico.

— Cliff.meyers

5

Em qualquer produto entregue, o número esperado desse tipo de erro deve ser zero. A utilidade dessas informações para o cliente é zero. Em ambas as contagens, não há razão para apresentar um rastreamento de pilha. Se houver algum contexto útil, ele deverá 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 confiar no cliente para enviá-las a você. 99,99% do tempo eles não vão. Você deve instalar um sistema de relatório de erros que envie as informações automaticamente, com apenas um "ok" do cliente.

— ddyer
fonte

Eu recomendaria esta resposta apenas para a seguinte linha: "A utilidade dessas informações para o cliente é zero". . Quaisquer detalhes técnicos sobre as partes internas de um produto devem ser ocultados, a menos que haja um bom motivo para não fazer isso pelo simples motivo de simplicidade e usabilidade para o usuário final do produto.

— Kjartan #