Une trace de pile doit-elle figurer dans le message d'erreur présenté à l'utilisateur?
J'ai un peu d'argument sur mon lieu de travail et j'essaie de savoir qui a raison et quelle est la bonne chose à faire.
Contexte: une application Web intranet que nos clients utilisent pour la comptabilité et autres choses ERP.
Je suis d'avis qu'un message d'erreur présenté à l'utilisateur (lorsque les choses plantent) devrait inclure autant d'informations que possible, y compris la trace de la pile. Bien sûr, il doit commencer par une belle "Une erreur s'est produite, veuillez soumettre les informations ci-dessous aux développeurs" dans de grandes lettres amicales.
Mon raisonnement est qu'une capture d'écran de l'application bloquée sera souvent la seule source d'information facilement accessible. Bien sûr, vous pouvez essayer de mettre la main sur le ou les administrateurs système du client, tenter d'expliquer où se trouvent vos fichiers journaux, etc., mais cela sera probablement lent et douloureux (la plupart du temps, parler aux représentants du client l'est).
De plus, avoir une information immédiate et complète est extrêmement utile dans le développement, où vous n'avez pas besoin d'aller chercher dans 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 comment 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 pour la sécurité. Naturellement, les clients (au moins un que je connaisse) ont pris cela au pied de la lettre et demandent maintenant que les messages soient nettoyés.
Je ne vois pas comment un attaquant potentiel pourrait utiliser une trace de pile pour comprendre quelque chose qu'il n'aurait pas pu comprendre auparavant. Y a-t-il des exemples, des preuves documentées que quelqu'un ait jamais fait cela? Je pense que nous devrions combattre cette idée stupide, mais peut-être que je suis le fou ici, alors ...
Qui a raison?
J'ai tendance à créer un journal des applications, soit dans la base de données ou dans un fichier, et y enregistrer 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 prennent pas la peine de les signaler avec vous, afin que vous puissiez avoir une meilleure idée de l'emplacement des problèmes.
Si votre site est installé dans l'environnement d'un client et que vous ne pouvez pas l'atteindre, vous pouvez demander au service informatique sur site de vous envoyer un extrait basé sur l'erreur no.
L'autre chose que vous pourriez envisager est d'envoyer les détails du système par e-mail des erreurs à une boîte aux lettres que vous avez vue, afin que vous sachiez quand les choses vont mal.
Fondamentalement, avoir un système qui renverse ses tripes quand quelque chose ne va pas n'inspire pas confiance aux utilisateurs non techniques - cela a tendance à leur faire peur en pensant que quelque chose ne va pas (par exemple, combien de BSOD comprenez-vous et comment vous vous sentez quand on arrive)?
Sur stacktrace:
Dans .Net, la trace de la pile affichera la trace complète directement dans les assemblages principaux MS, et révélera des détails sur les technologies que vous utilisez, ainsi que sur les versions possibles. Cela donne aux intrus des informations précieuses sur les faiblesses possibles qui pourraient être exploitées.
Oui, il y en a beaucoup.
Une trace de pile peut révéler
- quel algorithme de cryptage vous utilisez
- quels sont les chemins d'accès 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 marque de base de données se trouve derrière votre front-end
... La liste se rallonge de plus en plus. Fondamentalement, chaque décision de conception dans une grande application pourrait être pertinente pour la sécurité, et presque toutes peuvent être révélées via des noms de méthode ou de module. Remarquez, cela ne signifie pas qu'il n'a pas encore de sens d'afficher une trace de pile si l'environnement auquel il est soumis est sûr (par exemple, un intranet plutôt qu'un site Internet), mais le coût de la sécurité n'est certainement pas nul .
Le fait est que ce n'est pas notre travail principal de nous faciliter les choses. C'est notre travail de faciliter les choses pour l'utilisateur final. Pour nous, une trace de pile ressemble à une information extrêmement utile à fournir à un développeur. Pour un utilisateur, cela ressemble à du 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 auprès des administrateurs système, les obtenir des utilisateurs finaux est encore pire.
En ce qui concerne la sécurité, vous pourriez avoir un point si c'était une application de bureau. Dans ce cas, l'impression d'une trace de pile ne fournit rien que l'attaquant ne sache déjà. Sur une application Web, ces informations ne sont pas déjà disponibles pour un attaquant. Vous exposez en effet des détails internes qui rendront une attaque un lot plus facile.
Pourquoi ne pas contourner les deux sources de préoccupation et recevoir automatiquement des rapports d'exception? De cette façon, vous n'avez même pas à vous soucier des personnes qui ne signalent pas d'erreurs.
Jetez un oeil à cette question de IT Security SE . En bref, une trace de pile peut donner à l'attaquant plus d'informations avec lesquelles travailler. Plus l'attaquant dispose d'informations, plus il est susceptible de pénétrer 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 devez fournir ces informations aux attaquants.
De toute façon, vous pouvez profiter de la plupart des avantages d'une bonne journalisation du backend. C'est un peu moins pratique, mais cela ne vaut probablement pas la peine de risquer la sécurité de votre système et de déranger vos clients.
Vous pouvez envisager de ne pas afficher de trace de pile pour les raisons suivantes.
Sécurité
Afficher une trace de pile révèle que les surfaces d'attaque pourraient être 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 vous ferait beaucoup de mal.
Expérience utilisateur
Pour la meilleure expérience de l'utilisateur, une trace de piste est trop d'informations. Oui, les informations appropriées sur une condition d'erreur doivent être enregistrées et traitées par un ingénieur. Cependant, demander à un utilisateur de faire ce que vous pouvez automatiser ne sera pas le meilleur pour l'utilisateur.
Votre réputation
Chaque fois qu'une trace de pile est affichée sur un site Web, elle semble mauvaise. 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 la demande n'a pas été bien pensée. De nombreuses applications mal écrites affichent trop souvent les traces de pile car c'est la valeur par défaut dans certains frameworks comme ASP.Net.
Réponse courte: dans un extranet ou un site Internet, il est logique de ne pas afficher la trace de pile. Dans un intranet, les avantages de montrer la trace de pile dépassent ceux de la masquer.
Réponse longue:
La même chose m'est arrivée au travail. Je pensais que si une application échoue, elle devrait échouer bruyamment.
Mais ensuite, ils m'ont expliqué qu'un hacker potentiel pouvait inférer beaucoup de choses d'une trace de stack.
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 c'est pour lui et que moins un pirate informatique connaît votre plate-forme, mieux c'est pour vous.
De plus, les entreprises ne souhaitent pas divulguer comment un pirate informatique a pénétré dans leurs systèmes.
D'un autre côté, c'est un intranet, et je pense que les avantages de savoir immédiatement ce qui n'a pas fonctionné sans avoir à rechercher un fichier journal présente un grand avantage et les risques de sécurité de afficher un stacktrace à l'intérieur des limites de votre entreprise n'est pas aussi élevé qu'ils le disent.
Dans tout produit livré, le nombre attendu de ce type d'erreur doit être nul. L'utilité de cette information pour le client est nulle. Sur les deux points, il n'y a aucune raison de présenter une trace de pile. S'il existe un contexte utile, il doit être présenté de manière conviviale pour le client, et non comme une trace de pile.
En revanche, si le nombre réel d'occurrences n'est pas nul, vous avez désespérément besoin de ces informations et ne devez pas compter sur le client pour vous les envoyer. 99,99% du temps, ils ne le feront pas. Vous devez installer un système de reporing de bogue qui soumet automatiquement les informations, avec seulement un "ok" du client.