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
la source
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 .Réponses:
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.
la source
Oui, il y en a beaucoup.
Une trace de pile peut révéler
... 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. .
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.
la source