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

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

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.

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 .

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.

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.

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.

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.

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.