Sollte ein Stack-Trace in der Fehlermeldung enthalten sein, die dem Benutzer angezeigt wird?

45

Ich habe ein bisschen Streit an meinem Arbeitsplatz und ich versuche herauszufinden, wer Recht hat und was das Richtige ist.

Kontext: Eine Intranet-Webanwendung, die unsere Kunden für das Rechnungswesen und andere ERP-Aufgaben verwenden.

Ich bin der Meinung, dass eine Fehlermeldung, die dem Benutzer angezeigt wird (wenn Dinge abstürzen), so viele Informationen wie möglich enthalten sollte, einschließlich des Stack-Trace. Natürlich muss es mit einem netten "Ein Fehler ist aufgetreten, bitte senden Sie die folgenden Informationen an die Entwickler" in großen, freundlichen Buchstaben beginnen.

Meiner Meinung nach ist ein Screenshot der abgestürzten Anwendung häufig die einzige leicht verfügbare Informationsquelle. Sicher, Sie können versuchen, die Systemadministratoren des Clients zu erreichen, zu erklären, wo sich Ihre Protokolldateien befinden, usw., aber das wird wahrscheinlich langsam und schmerzhaft sein (dies geschieht meistens, wenn Sie mit den Kundenvertretern sprechen).

Eine sofortige und vollständige Information ist auch für die Entwicklung von großem Nutzen, da Sie nicht die Protokolldateien durchsuchen müssen, um bei jeder Ausnahme das zu finden, was Sie benötigen. (Aber das könnte mit einem Konfigurationsschalter gelöst werden.)

Leider gab es eine Art "Sicherheitsprüfung" (keine Ahnung, wie sie das ohne die Quellen gemacht haben ... aber was auch immer) und sie beklagten sich über die vollständigen Ausnahmemeldungen, in denen sie als Sicherheitsbedrohung angeführt wurden. Natürlich haben die Clients (von denen mindestens einer bekannt ist) dies zum Nennwert angenommen und fordern nun, dass die Nachrichten bereinigt werden.

Ich verstehe nicht, wie ein potenzieller Angreifer mithilfe eines Stack-Traces herausfinden kann, was er zuvor nicht herausgefunden hat. Gibt es Beispiele, einen dokumentierten Beweis dafür, dass jemand das jemals getan hat? Ich denke, wir sollten diese dumme Idee bekämpfen, aber vielleicht bin ich hier der Dummkopf, also ...

Wer hat recht

security error-handling Vilx-
quelle
25
Beeindruckend. Einfach wow. " Unfortunately there has been some kind of "Security audit"" - Ernst? Was ist das für eine Einstellung? Die Sicherheitsüberprüfungen sind zu Ihrem Vorteil - um Ihre Systeme zu verbessern und Probleme zu finden, bevor die Bösen es tun. Sie sollten sich wirklich überlegen, mit ihnen zu arbeiten, nicht gegen sie. Auch könnten Sie versuchen, mehr Informationen über die Sicherheit PoV über bekommen Informationssicherheit .
AviD
7
Übrigens muss eine Sicherheitsüberprüfung nicht unbedingt auf den Quellcode zugreifen, sondern hat wahrscheinlich einen Black-Box-Penetrationstest durchgeführt, der simuliert, was ein böswilliger Benutzer tun würde - versuchen Sie, die Anwendung als Benutzer anzugreifen. Obwohl ich damit einverstanden bin, dass der Zugriff auf den Quellcode eine viel effektivere Form der Prüfung ermöglicht hätte. :-)
AviD
1
@AviD - in Wahrheit weiß ich nicht, was sie analysiert haben, aber aus einigen Berichten ging hervor, dass es mir wie ein Black-Box-Test vorkam. Um ehrlich zu sein, möchte ich nicht gegen sie arbeiten. In der Tat mochte ich die Nachrichten, als ich sie hörte. Aber diese besondere "Verwundbarkeit" von ihnen scheint mir albern. Bei jeder Sicherheitsentscheidung müssen Sie die Bedrohungsreduzierung gegen die Usability-Reduzierung abwägen. In diesem Fall wird die Benutzerfreundlichkeit meines Erachtens mehr beeinträchtigt als die Sicherheit verbessert.
Vilx
1
Ich bin mit dem Wiegen einverstanden, aber mit der Anwendung bin ich nicht einverstanden. Es schadet der Sicherheit mehr als Sie denken, und ich denke auch, dass Ihr Weg (dies selbst getan zu haben, bis ich mit einigen der Benutzer gesprochen habe ...) für die Benutzerfreundlichkeit schlechter ist. Denken Sie aufgabenorientiert darüber nach - wie @ Jons Antwort sagte, wird die Arbeit des Benutzers auf seine Weise viel besser erledigt. Der Benutzer muss sich nicht um den Stack kümmern (es sei denn, Ihre Benutzer sind die Entwickler ...). Aber meine Expertise liegt in der Sicherheit - und die Risiken sind real.
AviD
1
@AviD - Vielleicht können Sie mich auf einige Ressourcen verweisen, die erklären, wie gefährlich ein Stack-Trace sein kann? Ich bin bereit, das zu akzeptieren, aber ich möchte etwas mehr als das allgemeine Prinzip "Zeige nur, was du brauchst".
Vilx

Antworten:

73

Ich neige dazu, ein Anwendungsprotokoll zu erstellen, entweder in der Datenbank oder in einer Datei, und alle diese Informationen in dieses Protokoll aufzunehmen. Sie können dem Benutzer dann eine Fehlernummer geben, die angibt, mit welchem ​​Protokollelement der Fehler zusammenhängt, damit Sie ihn zurückerhalten können. Dieses Muster ist auch nützlich, da Sie Fehlern folgen können, auch wenn sich die Benutzer nicht darum kümmern, sie mit Ihnen zu erheben, damit Sie eine bessere Vorstellung davon bekommen, wo die Probleme liegen.

Wenn Ihre Site in einer Client-Umgebung installiert ist und Sie sie nicht erreichen können, können Sie die IT-Abteilung vor Ort bitten, Ihnen einen Auszug zu senden, der auf der Fehlernummer basiert.

Das andere, was Sie in Betracht ziehen könnten, ist, die System-E-Mail-Details von Fehlern an eine Mailbox zu senden, die Sie im Blick haben, damit Sie wissen, wenn etwas schief geht.

Grundsätzlich ein System zu haben, das seinen Mut verliert, wenn etwas nicht stimmt, weckt kein Vertrauen bei nicht-technischen Anwendern - es neigt dazu, sie zu verunsichern, dass etwas sehr falsch ist (z. B. wie viel von einem BSOD verstehen Sie und wie tun Sie das?) fühlst du wenn man auftaucht)?

Auf Stacktrace:

In .Net zeigt der Stack-Trace die vollständige Ablaufverfolgung bis in die MS-Core-Assemblys und zeigt Details zu den von Ihnen verwendeten Technologien und möglichen Versionen an. Dies gibt Eindringlingen wertvolle Informationen über mögliche Schwachstellen, die ausgenutzt werden könnten.

Jon Egerton
quelle
6
Ich mag Ihre Antwort, weil sie einen "Mittelweg" darstellt - nicht anzeigen, aber das Nachschlagen von Ausnahmen vereinfachen. Ich werde versuchen, das jetzt voranzutreiben, ich hoffe, dass sie zustimmen werden. Danke!
Vilx
2
Ich denke, das ist so ziemlich der Standard "ausgereiften" Ansatz. Auch Stacktrace bietet eine Fülle von Informationen, allerdings muss ich noch eine Lösung finden, die automatisch Statusinformationen zusammen mit dem Stacktrace protokolliert (ohne dass sich der Code überall ändert). Es scheint, dass das Schreiben und Anhängen eines eigenen Debuggers ein möglicher Weg ist, dessen Implementierung jedoch alles andere als trivial ist.
Daniel B
@DanielB: In Web-Apps ist es möglich, einige gängige Dinge (wie Benutzer-ID, Client-ID usw.) aus der Sitzung / dem Cache abzurufen - da diese "global" bestehen bleiben, können selbst so viele Informationen die Fehlerwiedergabe erheblich verbessern. Körniger als das ist sehr schwierig, wie Sie sagen.
Jon Egerton
2
Einige Benutzer sehr kritischer Anwendungen fordern sofortige Lösungen für alle Fehler, die den normalen Geschäftsverlauf beeinträchtigen. Der gesamte Kommunikationsprozess, der verschiedene Disziplinen umfasst, nur damit der Fehlerlöser den Fehlerstapel in den Griff bekommt, kann 1 Stunde oder mehr in Anspruch nehmen, wenn der Fehler spät in der Nacht oder am Wochenende auftritt.
Tulains Córdova
1
@ user1598390: Einverstanden. In diesem Fall kann das Kopieren der Fehlerdetails in ein überwachtes Support-Postfach das Sammeln von Informationen beschleunigen, sodass die Support-Mitarbeiter bereits vor dem Benutzer wissen, dass ein Fehler aufgetreten ist.
Jon Egerton
29

Ja, es gibt viele.

Ein Stack-Trace kann aufdecken

  • Welchen Verschlüsselungsalgorithmus verwenden Sie?
  • Welche vorhandenen Pfade gibt es auf Ihrem Anwendungsserver?
  • ob Sie die Eingabe ordnungsgemäß bereinigen oder nicht
  • wie Ihre Objekte intern referenziert werden
  • Welche Version und Marke der Datenbank steckt hinter Ihrem Front-End?

... Die Liste geht weiter und weiter. Grundsätzlich kann jede Design - Entscheidung in einer großen Anwendung könnte sein , sicherheitsrelevanten und fast alle von ihnen durch Verfahren oder Modulnamen werden verschenkt. Wohlgemerkt, das bedeutet nicht, dass es immer noch keinen Sinn macht, einen Stack-Trace anzuzeigen, wenn die Umgebung, in der er gesendet wird, sicher ist (z. B. ein Intranet anstelle einer mit dem Internet verbundenen Website), aber die Sicherheitskosten sind definitiv nicht null .

Kilian Foth
quelle
6
Ich stimme größtenteils zu, aber einige dieser Dinge sollten keine Rolle spielen. Zum Beispiel sollte der verwendete Verschlüsselungsalgorithmus nicht geheim sein, um Ihr System zu schützen.
Oleksi
3
Es sollte keine Rolle spielen, aber die Welt ist unvollkommen und oftmals auch. Aus diesem Grund ist die Tiefenverteidigung (viele Dinge gleichzeitig zu tun, die ausreichen sollten , wenn sie perfekt wären) wichtig.
Kilian Foth
3
Ehrlich gesagt, wenn ein Stack-Trace irgendetwas aufdeckt , das einem Angreifer helfen könnte, dann machen Sie es falsch !
Mark Booth
3
@MarkBooth statistisch gesehen, haben Sie wahrscheinlich sind es falsch zu machen. Nein, verkratzen Sie das - statistische Gewissheit, dass Sie einen Teil davon falsch verstehen. Möchten Sie die Angreifer wirklich dazu bringen, Ihre Sicherheitslücken zu finden, bevor Sie dies tun?
AviD
1
@AviD - Nein, ich bin einverstanden. Der überzeugendste Grund, Stapelverfolgungen für Benutzer nicht anzuzeigen, besteht darin, dass sie keine Ahnung haben, was sie damit tun sollen, und Ihr Protokollierungssystem sollte sowohl sicher als auch in der Lage sein, einen weitaus größeren Status als ein Bildschirmabzug zu erfassen einer Webseite jemals könnte.
Mark Booth
15

Die Sache ist, es ist nicht unsere Hauptaufgabe, die Dinge für uns selbst einfacher zu machen. Es ist unsere Aufgabe, dem Endverbraucher die Arbeit zu erleichtern. Für uns ist ein Stack-Trace eine äußerst nützliche Information, die einem Entwickler zur Verfügung steht. Für einen Benutzer sieht es aus wie komplettes Kauderwelsch, das überhaupt nichts nützt. Selbst wenn Sie ihnen etwas anderes mitteilen, verinnerlichen sie es nicht. Wenn Sie der Meinung sind, dass es schwierig ist, diese Informationen von Systemadministratoren zu erhalten, ist es noch schlimmer, sie von Endbenutzern zu erhalten.

Was die Sicherheit anbelangt, haben Sie vielleicht einen Punkt, wenn es sich um eine Desktop-Anwendung handelte. In diesem Fall bietet das Drucken eines Stack-Trace nichts, was ein Angreifer noch nicht weiß. In einer Web-App sind diese Informationen für einen Angreifer noch nicht verfügbar. Sie legen in der Tat interne Details offen, die einen Angriff viel einfacher machen.

Warum umgehen Sie nicht beide Anlass zur Sorge und lassen sich automatisch Ausnahmemeldungen zusenden? Auf diese Weise müssen Sie sich nicht einmal Sorgen machen, dass Personen keine Fehler melden.

Karl Bielefeldt
quelle
2
Der Benutzer profitiert von einer schnellen Lösung seines Problems dank der Informationen, die der Stack-Trace liefert. Aber ich verstehe, worum es geht.
Tulains Córdova
11

Werfen Sie einen Blick auf diese Frage der IT Security SE . Kurz gesagt, ein Stack-Trace kann dem Angreifer mehr Informationen zur Verfügung stellen, mit denen er arbeiten kann. Je mehr Informationen der Angreifer hat, desto wahrscheinlicher ist es, dass er in Ihr System eindringt. Ich würde meine Sicherheit nicht darauf stützen, dass Stack-Traces immer ausgeblendet sind, aber das bedeutet auch nicht, dass Sie diese Informationen an Angreifer weitergeben sollten.

Sie können die meisten Vorteile einer ordnungsgemäßen Backend-Protokollierung trotzdem nutzen. Es ist etwas weniger praktisch, aber es lohnt sich wahrscheinlich nicht, die Sicherheit Ihres Systems zu riskieren und Ihre Kunden zu verärgern.

Oleksi
quelle
8

Möglicherweise möchten Sie aus den folgenden Gründen keinen Stack-Trace anzeigen.

Sicherheit

Wenn Sie eine Stapelverfolgung anzeigen, werden mögliche Angriffsflächen für Hacker angezeigt. Intranets sind nicht immun gegen Hacking. Es würde sich schlecht auf Sie auswirken, wenn Ihr Netzwerk aufgrund einer Anwendung gehackt würde, für die Sie verantwortlich sind

Benutzererfahrung

Für die beste Benutzererfahrung ist eine Spurverfolgung zu viel Information. Ja, die richtigen Informationen zu einem Fehlerzustand sollten von einem Techniker protokolliert und beachtet werden. Es ist jedoch nicht das Beste für den Benutzer, einen Benutzer zu bitten, das zu tun, was Sie automatisieren können.

Ihr Ruf

Immer wenn ein Stack-Trace auf einer Website angezeigt wird, sieht es schlecht aus. Die meisten Menschen haben keine Ahnung, was es ist, und das gibt ihnen das Gefühl, dass die Website nicht freundlich zu ihnen ist. Für diejenigen, die wissen, was es ist, kann dies ein Hinweis darauf sein, dass die Anwendung nicht gut durchdacht war. Viele schlecht geschriebene Anwendungen zeigen viel zu oft Stack-Traces an, da dies in einigen Frameworks wie ASP.Net der Standard ist.

Tom Resing
quelle
6
Als Softwareentwickler sehe ich auf dem Bildschirm eine Stapelverfolgung, aber mein direkter Hinweis lautet: "Hier ist ein Bozo, der nichts über den Umgang mit Fehlern weiß, sich weniger um sie kümmert und sich wahrscheinlich noch weniger um Benutzer". Andere drehen sich um "das ist beschissene Software, nicht an, funktioniert nicht, die Fehlerbehandlung funktioniert nicht" und "WTF ... ich mache diesen Job nicht für ihn". Was Ihr Benutzer wissen möchte, ist was Er muss es reparieren. Wie macht der Stack-Trace das?
Mattnz
6

Kurze Antwort: In einem Extranet oder einer Internetseite ist es sinnvoll, den Stacktrace nicht anzuzeigen. In einem Intranet übertreffen die Vorteile des Anzeigens des Stacktraces die des Ausblendens.

Lange Antwort:

Das gleiche passierte mir bei der Arbeit. Früher dachte ich, wenn eine App ausfällt, sollte sie laut ausfallen.

Aber dann erklärten sie mir, dass ein potentieller Hacker eine Menge Dinge von einem Stacktrace aus infizieren könnte.

Ich glaube, es besteht kein Beweisbedarf. Es ist offensichtlich, dass je mehr ein Hacker über Ihre Plattform Bescheid weiß , desto besser für ihn und je weniger ein Hacker über Ihre Plattform Bescheid weiß , desto besser für Sie .

Auch Unternehmen wollen nicht offenlegen, wie ein Hacker in ihre Systeme eingebrochen ist.

Auf der anderen Seite handelt es sich um ein Intranet , und ich denke, der Vorteil, sofort zu wissen, was ohne die Suche in einer Protokolldatei schief gelaufen ist, ist von großem Vorteil, und das Sicherheitsrisiko, einen Stacktrace innerhalb der Grenzen Ihres Unternehmens anzuzeigen, ist nicht so hoch wie Sie sagen.

Tulains Córdova
quelle
1
Was sind einige der "Vorteile, wenn man sofort weiß, was schief gelaufen ist", und warum können sie nicht aus einer Protokolldatei abgerufen werden? Es scheint, dass Sie mit einem Intranet noch einfacher auf eine Protokolldatei zugreifen können als mit einer Client-Site.
Wonko the Sane
In meinem Szenario gibt es kritische Anwendungen mit der Priorität "7/24". Der Benutzer ruft den Helpdesk an. Wenn das Problem ein Anwendungsfehler oder eine Ausnahme ist, ruft der Helpdesk den Betreuer an, der möglicherweise nicht vor Ort ist. Mit den Fehlerinformationen kann der Experte eine Person vor Ort zu einer Problemumgehung anweisen. Oftmals ist die eingesparte Zeit kostbar, wenn die App geschäftskritisch ist. Wenn der Experte, der sich außerhalb der Geschäftsräume befindet, zuerst eine Verbindung zum Unternehmen herstellen, das Protokoll durchsuchen usw. muss, könnte eine wichtige Geschäftsfunktion unnötig warten.
Tulains Córdova
3
@ user1598390 also erstelle einen Log-Anzeigemechanismus. Auf einer einfachen Webseite können Sie die Vorfall-ID eingeben und der Helpdesk kann das gesamte relevante Protokoll anzeigen. Natürlich den Zugriff auf diese Funktion einschränken und so weiter ...
AviD
Nur weil sich eine App im Intranet Ihres Unternehmens befindet, bedeutet dies nicht, dass sich keine böswilligen Benutzer darin befinden. Es gibt viele verärgerte Mitarbeiter, die ein internes System möglicherweise zu ihrem eigenen Vorteil missbrauchen. Da diese Mitarbeiter viel über das Unternehmen und seine Richtlinien wissen, können sie tatsächlich gefährlicher sein als ein interner Hacker. Das Durchsuchen von Protokolldateien ist eine ziemlich einfache Aufgabe, insbesondere wenn Sie bewährte Methoden befolgen und Fehler in einer bestimmten Fehlerprotokolldatei protokollieren.
cliff.meyers
5

In jedem gelieferten Produkt sollte die erwartete Anzahl dieser Art von Fehler Null sein. Der Nutzen dieser Informationen für den Kunden ist null. In beiden Fällen gibt es keinen Grund, einen Stack-Trace vorzulegen. Wenn es einen nützlichen Kontext gibt, sollte er kundenfreundlich und nicht als Stack-Trace dargestellt werden.

Wenn die tatsächliche Anzahl der Vorkommen jedoch nicht Null ist, benötigen Sie diese Informationen dringend und sollten sich nicht darauf verlassen, dass der Kunde sie an Sie sendet. 99,99% der Zeit werden sie nicht. Sie sollten ein System zur Fehlerberichterstattung installieren, das die Informationen automatisch und nur mit einem "OK" des Kunden übermittelt.

ddyer
quelle
Ich würde diese Antwort nur für die folgende Zeile positiv bewerten: "Der Nutzen dieser Informationen für den Kunden ist Null." . Alle technischen Details zu den Einbauten eines Produkts sollten ausgeblendet werden, es sei denn, es gibt einen guten Grund, dies aus Gründen der Einfachheit und Benutzerfreundlichkeit für den Endbenutzer des Produkts nicht zu tun.
Kjartan,