Une trace de pile doit-elle figurer dans le message d'erreur présenté à l'utilisateur?

45

J'ai un peu de discussion sur mon lieu de travail et j'essaie de trouver qui a raison et quelle est la bonne chose à faire.

Contexte: une application Web intranet que nos clients utilisent pour la comptabilité et d’autres progiciels de gestion intégrés.

Je suis d'avis qu'un message d'erreur présenté à l'utilisateur (en cas de plantage) devrait inclure autant d'informations que possible, y compris le suivi de la pile. Bien sûr, il doit commencer par un beau message "Une erreur est survenue, veuillez envoyer les informations ci-dessous aux développeurs" en grosses lettres amicales.

Mon raisonnement est qu'une capture d'écran de l'application en panne sera souvent la seule source d'informations facilement disponible. Bien sûr, vous pouvez essayer de contacter le (s) administrateur (s) du système du client, tenter d’expliquer où sont vos fichiers journaux, etc.

En outre, disposer d'informations complètes et immédiates est extrêmement utile en développement, car vous n'avez pas à parcourir les fichiers journaux pour trouver ce dont vous avez besoin à chaque exception. (Mais cela pourrait être résolu avec un commutateur de configuration.)

Malheureusement, il y a eu une sorte d '"audit de sécurité" (aucune idée de la façon dont ils l'ont fait sans les sources ... mais peu importe), et ils se sont plaints des messages d'exception complets les citant comme une menace à la sécurité. Naturellement, les clients (au moins un de ceux que je connais) ont pris cela au sérieux et exigent maintenant que les messages soient nettoyés.

Je ne vois pas comment un attaquant potentiel pourrait utiliser une trace de pile pour découvrir quelque chose qu'il n'aurait jamais pu comprendre auparavant. Existe-t-il des exemples, des preuves documentées montrant que quelqu'un a déjà fait cela? Je pense que nous devrions lutter contre cette idée stupide, mais peut-être que je suis idiot ici, alors ...

Qui a raison

security error-handling

— Vilx-
source

25

Sensationnel. Juste wow. " Unfortunately there has been some kind of "Security audit"" - Sérieusement? Quel genre d'attitude est-ce? Les audits de sécurité sont à votre avantage - pour améliorer vos systèmes, pour détecter les problèmes avant les méchants. Vous devriez vraiment envisager d'essayer de travailler avec eux, pas contre eux. Vous pouvez également essayer d'obtenir plus d'informations sur la valeur de sécurité dans Information Security .

— AviD

7

Et d'ailleurs, un audit de sécurité n'a pas nécessairement besoin d'accéder au code source, ils ont probablement fait un test d'intrusion dans une boîte noire, simulant ce qu'un utilisateur malveillant ferait - essayer d'attaquer l'application en tant qu'utilisateur. Bien que je convienne que l'accès au code source aurait pu permettre une forme d'audit beaucoup plus efficace. :-)

— AviD

1

@AviD - en vérité, je ne sais pas ce qu'ils ont analysé, mais d'après certains rapports, cela m'a semblé être un test de boîte noire. Pour être honnête, je ne veux pas travailler contre eux. En effet, j'ai aimé les nouvelles quand je les ai entendues. Mais cette "vulnérabilité" particulière de la leur semble ridicule. Dans chaque décision de sécurité, vous devez peser la réduction de la menace par rapport à la réduction de la convivialité. Dans ce cas, je pense que cela réduit beaucoup plus la convivialité que la sécurité.

— Vilx-

1

Je suis très d'accord sur la pesée, mais je ne suis pas d'accord sur son application. Cela nuit plus à la sécurité que vous ne le pensez, et je pense aussi que votre façon de faire (après l'avoir fait moi-même aussi, jusqu'à ce que je parle à certains utilisateurs ...) est pire pour la facilité d'utilisation. Pensez-y en termes de tâches - comme le dit la réponse de @ Jon, son travail améliore considérablement le travail de l'utilisateur. L'utilisateur n'a pas besoin de se soucier de la pile (à moins que vos utilisateurs soient les développeurs ...), mais mon expertise est dans la sécurité - et les risques sont réels.

— AviD

1

@AviD - Peut-être pourriez-vous m'indiquer des ressources expliquant en quoi une trace de pile peut être dangereuse? Je suis prêt à accepter cela, mais je veux quelque chose de plus que le principe général de "ne montrer que ce que vous devez".

— Vilx-

73

J'ai tendance à créer un journal d'application, sous forme de base de données ou dans un fichier, et à consigner toutes ces informations. Vous pouvez ensuite donner à l'utilisateur un numéro d'erreur, qui identifie l'élément de journal auquel l'erreur est liée, afin que vous puissiez le récupérer. Ce modèle est également utile car vous pouvez suivre les erreurs même si les utilisateurs ne vous dérangent pas pour les soulever, vous pouvez ainsi avoir une meilleure idée de l'endroit où se trouvent les problèmes.

Si votre site est installé dans l'environnement d'un client et que vous ne pouvez pas y accéder, vous pouvez faire en sorte que le service informatique du site vous envoie un extrait basé sur l'erreur no.

Vous pouvez également envisager d’envoyer les informations du système par courrier électronique contenant les erreurs dans une boîte aux lettres visible, afin que vous sachiez si tout va mal.

Avoir fondamentalement un système qui a des tripes quand quelque chose ne va pas n'inspire pas la confiance des utilisateurs non-techniques - cela les fait peur en leur faisant croire que quelque chose ne va pas (par ex. tu sens quand on monte)?

Sur stacktrace:

Dans .Net, la trace de pile affichera la trace complète directement dans les assemblys centraux issus de MS, et révélera des détails sur les technologies que vous utilisez, ainsi que les versions possibles. Cela donne aux intrus des informations précieuses sur les faiblesses possibles qui pourraient être exploitées.

— Jon Egerton
source

6

J'apprécie votre réponse car elle présente une "voie moyenne" - ne s'affiche pas, mais facilite la recherche d'exceptions. Je vais essayer de faire pression pour cela maintenant, j'espère qu'ils seront d'accord. Merci!

— Vilx-

2

Je pense que c'est à peu près l'approche standard "mature". En outre, stacktrace fournit une mine d'informations, mais je n'ai pas encore trouvé de solution permettant de journaliser automatiquement les informations d'état avec stacktrace (sans modification du code partout). Il semble que l’écriture de votre propre débogueur et l’attachement de celui-ci constituent une solution mais sont loin d’être faciles à implémenter.

— Daniel B

@DanielB: Dans les applications Web, il est possible de récupérer certains éléments courants (tels que ID utilisateur, ID client, etc.) à partir de la session / du cache - car ils persistent «globalement», même ces nombreuses informations peuvent aider à reproduire les erreurs de manière importante. Plus granulaire que cela est très délicat, comme vous dites.

— Jon Egerton

2

Certains utilisateurs d’applications très critiques exigent des solutions immédiates à toute erreur entravant le cours normal des activités. Tout le processus de communication impliquant diverses procédures juste pour que le solutionneur d'erreurs puisse récupérer la pile d'erreurs peut facilement prendre 1 heure ou plus lorsque l'erreur se produit tard le soir ou le week-end.

— Tulains Córdova

1

@ user1598390: accepté, auquel cas la copie des détails de l'erreur dans une boîte aux lettres d'assistance surveillée peut accélérer la collecte d'informations, à tel point que le personnel de l'assistance sait que quelque chose a déjà été cassé avant l'utilisateur.

— Jon Egerton

29

Oui, il y en a beaucoup.

Une trace de pile peut révéler

quel algorithme de chiffrement vous utilisez
quels sont les chemins existants sur votre serveur d'applications
si vous désinfectez correctement l'entrée ou non
comment vos objets sont référencés en interne
quelle version et quelle marque de base de données se cache derrière votre front-end

... La liste se rallonge de plus en plus. En principe, chaque décision de conception dans une application volumineuse peut être liée à la sécurité, et presque toutes peuvent être divulguées sous forme de noms de méthodes ou de modules. Cela dit, cela ne veut pas dire qu'il n'est pas toujours logique d'afficher une trace de pile si l'environnement soumis est sûr (par exemple, un intranet plutôt qu'un site Web accessible sur Internet), mais le coût de la sécurité est vraiment non nul. .

— Kilian Foth
source

6

Je suis d'accord pour la plupart, mais certaines de ces choses ne devraient pas avoir d'importance. Par exemple, l'algorithme de chiffrement que vous utilisez ne devrait pas nécessairement être secret pour sécuriser votre système.

— Oleksi

3

Cela ne devrait pas avoir d'importance, mais le monde est imparfait et souvent, il l'est. C'est pourquoi la défense en profondeur (faire plusieurs choses en même temps, cela devrait suffire si elles étaient parfaites) importe.

— Kilian Foth

3

Franchement, si une trace de pile révèle tout ce qui pourrait aider un attaquant, vous le faites mal !

— Mark Booth

3

@MarkBooth statistiquement parlant, vous avez probablement sont faites mal. Non, grattez cela - la certitude statistique que vous vous trompez. Voulez-vous vraiment laisser les attaquants trouver vos problèmes de sécurité avant vous?

— AviD

1

@AviD - Non, je suis d'accord, la raison la plus convaincante pour ne pas afficher les traces de pile aux utilisateurs est qu'ils ne savent pas quoi en faire, et votre système de journalisation doit être à la fois sécurisé et capable de capturer bien plus qu'un simple écran. d'une page Web pourrait jamais.

— Mark Booth

15

Le problème, c’est que notre tâche principale n’est pas de nous faciliter la tâche. C'est notre travail de faciliter les choses pour l'utilisateur final. Pour nous, une trace de pile ressemble à une information extrêmement utile pour fournir un développeur. Pour un utilisateur, cela ressemble à un charabia complet qui ne sert à rien. Même si vous leur dites le contraire, ils ne l'intériorisent pas. Si vous pensez qu'il est difficile d'obtenir ces informations des administrateurs système, il est encore pire de les obtenir des utilisateurs finaux.

En ce qui concerne la sécurité, vous auriez peut-être un sens s'il s'agissait d'une application de bureau. Dans ce cas, imprimer une trace de pile ne fournit rien de ce qu'un attaquant ne sait déjà. Sur une application Web, ces informations ne sont pas encore disponibles pour un attaquant. Vous exposez en effet des détails internes qui faciliteront beaucoup l’ attaque .

Pourquoi ne pas contourner les deux sources d'inquiétude et recevoir des rapports d'exception automatiquement? De cette façon, vous n'avez même pas à vous soucier des personnes qui ne signalent pas les erreurs.

— Karl Bielefeldt
source

2

Les utilisateurs bénéficient d’une solution rapide à leur problème grâce aux informations fournies par la trace de la pile. Mais je comprends ton point.

— Tulains Córdova

11

Jetez un oeil à cette question de IT Security SE . En bref, une trace de pile peut donner à l'attaquant davantage d'informations à utiliser. Plus l’attaquant dispose d’informations, plus il est susceptible de pénétrer dans votre système. Je ne baserais pas ma sécurité sur le fait que les traces de pile sont toujours cachées, mais cela ne signifie pas non plus que vous devriez donner cette information aux attaquants.

De toute façon, vous pouvez tirer le meilleur parti des avantages d’une journalisation correcte. C'est un peu moins pratique, mais il ne vaut probablement pas la peine de risquer la sécurité de votre système et de contrarier vos clients.

— Oleksi
source

8

Vous pourriez envisager de ne pas afficher de trace de pile pour les raisons suivantes.

Sécurité

Le fait de montrer une trace de pile révèle que des surfaces d’attaque possibles seraient des pirates. Les intranets ne sont pas à l'abri du piratage. Si votre réseau était piraté à cause d’une application dont vous êtes responsable, cela aurait des conséquences négatives pour vous.

Expérience utilisateur

Pour la meilleure expérience de l'utilisateur, une trace de strack est trop d'informations. Oui, les informations appropriées concernant une condition d'erreur doivent être consignées et portées à l'attention d'un ingénieur. Cependant, demander à un utilisateur de faire ce que vous pouvez automatiser ne sera pas ce qu'il y a de mieux.

Votre réputation

Chaque fois qu'une trace de pile est affichée sur un site Web, cela semble mauvais. La plupart des gens n'ont aucune idée de ce que c'est et cela leur donne l'impression que le site Web n'est pas convivial pour eux. Pour ceux qui savent ce que c'est, cela peut indiquer que l'application n'a pas été bien pensée. De nombreuses applications mal écrites montrent trop souvent des traces de pile, car il s'agit de la configuration par défaut dans certains frameworks tels qu'ASP.Net.

— Tom Resing
source

6

En tant que développeur logiciel, lorsque je vois une trace de pile à l’écran, j’ai l’impression suivante: «Voici un bozo qui ne sait rien du traitement des erreurs, qui se soucie moins de celles-ci et probablement encore moins des utilisateurs». D'autres tournent autour de "c'est un logiciel de merde, pas sur ça ne marche pas, sa gestion des erreurs ne marche pas" et "WTF .... je ne fais pas ce boulot pour lui" Ce que votre utilisateur veut savoir, c'est ce que il doit faire pour le réparer. Comment la trace de la pile fait-elle cela?

— mattnz

6

Réponse courte: dans un extranet ou un site Internet, il est logique de ne pas afficher la pile. Dans un intranet, les avantages de montrer le stacktrace surpassent ceux de le cacher.

Longue réponse:

La même chose m'est arrivé au travail. J'avais l'habitude de penser que si une application échouait, elle devrait échouer bruyamment.

Mais ensuite, ils m'ont expliqué qu'un pirate informatique potentiel pourrait inférer beaucoup de choses d'un stacktrace.

Je pense qu'il n'y a pas besoin de preuve. Il est évident que plus un pirate informatique connaît votre plate-forme, mieux il en vaut pour lui, et moins un pirate informatique en sait sur votre plate-forme, mieux c'est .

De plus, les entreprises ne sont pas désireuses de révéler comment un pirate informatique a pénétré dans leurs systèmes.

De l’autre côté, c’est un intranet , et je pense que le fait de savoir immédiatement ce qui ne va pas sans chercher dans un fichier journal présente un grand avantage et que les risques pour la sécurité de montrer un stacktrace à l’intérieur des limites de votre entreprise ne sont pas aussi élevés. ils disent.

— Tulains Córdova
source

1

Quels sont certains des "avantages de savoir immédiatement ce qui ne va pas", et pourquoi ne peuvent-ils pas être extraits d'un fichier journal? Il semblerait qu'avec un intranet, vous puissiez accéder à un fichier journal encore plus facilement que depuis un site client.

— Wonko the Sane

Dans mon scénario, certaines applications critiques ont une priorité "7/24". Si le problème provient d'une erreur ou d'une exception d'application, le service d'assistance appelle le responsable, qui se trouve peut-être en dehors des locaux. Grâce aux informations d'erreur, l'expert peut demander à une personne sur site d'effectuer une solution de contournement ... Souvent, le temps économisé est précieux si l'application est critique pour l'entreprise. Si l'expert estime que, s'il doit d'abord se connecter à l'entreprise, consulter le journal, etc., une fonction essentielle de l'entreprise peut attendre inutilement.

— Tulains Córdova

3

@ user1598390 alors créez un mécanisme d'affichage du journal. Une simple page Web, entrez l’identifiant de l’incident et le service d’assistance peut consulter l’ensemble du journal correspondant. Bien sûr, limiter l'accès à cette fonctionnalité, et ainsi de suite ...

— AviD

Le simple fait qu'une application se trouve sur l'intranet de votre entreprise ne signifie pas qu'il n'y a pas d'utilisateurs malveillants. Il existe de nombreux employés mécontents qui pourraient très bien utiliser un système interne à leur avantage. Étant donné que ces employés en savent beaucoup sur la société et ses politiques, ils pourraient en réalité être plus dangereux qu'un pirate informatique interne. Parcourir les fichiers journaux est une tâche assez simple, surtout si vous suivez les bonnes pratiques et consignez également les erreurs dans un fichier journal des erreurs spécifique.

— cliff.meyers

5

Dans tout produit livré, le nombre attendu de ce type d'erreur doit être égal à zéro. L'utilité de cette information pour le client est zéro. Dans les deux cas, il n’ya aucune raison de présenter une trace de pile. S'il existe un contexte utile, il doit être présenté de manière conviviale et non comme une trace de pile.

D'autre part, si le nombre réel d'occurrences n'est pas égal à zéro, vous avez désespérément besoin de cette information et vous ne devez pas compter sur le client pour vous l'envoyer. 99,99% du temps, ils ne le feront pas. Vous devez installer un système de repérage de bogues qui soumet automatiquement les informations, avec uniquement un "ok" du client.

— Ddyer
source

Je voudrais upvote cette réponse pour la ligne suivante seule: "L'utilité de cette information pour le client est zéro." . Tous les détails techniques relatifs aux composants internes d'un produit doivent être masqués sauf s'il existe une bonne raison de ne pas le faire pour la simple raison de la simplicité et de la convivialité pour l'utilisateur final du produit.

— Kjartan