it-swarm.com.de

Sollte eine Stapelverfolgung in der Fehlermeldung enthalten sein, die dem Benutzer angezeigt wird?

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

Kontext: Eine Intranet-Webanwendung, die unsere Kunden für die Buchhaltung und andere ERP) Dinge 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 der Stapelverfolgung. Natürlich muss es mit einem netten "Ein Fehler ist aufgetreten, bitte senden Sie die folgenden Informationen an die Entwickler" in großen, freundlichen Briefen beginnen.

Meine Argumentation ist, dass ein Screenshot der abgestürzten Anwendung oft die einzige leicht verfügbare Informationsquelle ist. 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 (meistens mit den Kundenvertretern).

Eine sofortige und vollständige Information ist auch in der Entwicklung äußerst nützlich, da Sie nicht die Protokolldateien durchsuchen müssen, um zu finden, was Sie für jede Ausnahme benötigen. (Aber das könnte mit einem Konfigurationsschalter gelöst werden.)

Leider gab es eine Art "Sicherheitsüberprüfung" (keine Ahnung, wie sie das ohne die Quellen gemacht haben ... aber was auch immer), und sie beschwerten sich über die vollständigen Ausnahmemeldungen, in denen sie als Sicherheitsbedrohung angeführt wurden. Natürlich haben die Kunden (mindestens einer, den ich kenne) dies zum Nennwert genommen und fordern nun, dass die Nachrichten bereinigt werden.

Ich sehe nicht ein, wie ein potenzieller Angreifer mithilfe einer Stapelverfolgung etwas herausfinden könnte, was er vorher nicht hätte herausfinden können. Gibt es Beispiele, dokumentierte Beweise 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?

46
Vilx-

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

Wenn Ihre Site in der Umgebung eines Clients installiert ist und Sie sie nicht erreichen können, können Sie sich von der IT-Abteilung vor Ort einen Auszug senden lassen, der auf der Fehlernummer basiert.

Die andere Sache, die Sie in Betracht ziehen könnten, ist, dass das System E-Mail-Details von Fehlern an eine Mailbox sendet, die Sie sehen, damit Sie wissen, wenn etwas schief geht.

Grundsätzlich schafft ein System, das den Mut verliert, wenn etwas nicht stimmt, kein Vertrauen in nicht-technische Benutzer - es macht ihnen Angst, dass etwas sehr falsch ist (z. B. wie viel von einem BSOD verstehen Sie und wie du fühlst wenn einer auftaucht)?

Auf Stacktrace:

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

74
Jon Egerton

Ja, es gibt viele.

Eine Stapelspur kann aufdecken

  • welchen Verschlüsselungsalgorithmus verwenden Sie?
  • was sind einige vorhandene Pfade auf Ihrem Anwendungsserver
  • ob Sie Eingaben 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 ist jede Entwurfsentscheidung in einer großen Anwendung möglicherweise sicherheitsrelevant, und fast alle von ihnen können über Methoden- oder Modulnamen weitergegeben werden. Wohlgemerkt, das bedeutet nicht, dass es immer noch keinen Sinn macht, einen Stack-Trace anzuzeigen, wenn die Umgebung, an die er gesendet wird, sicher ist (z. B. ein Intranet anstelle einer mit dem Internet verbundenen Website), aber die Kosten für die Sicherheit sind definitiv nicht Null .

30
Kilian Foth

Die Sache ist, es ist nicht unsere Hauptaufgabe, uns die Dinge leichter zu machen. Es ist unsere Aufgabe, dem Endbenutzer die Arbeit zu erleichtern. Für uns scheint eine Stapelverfolgung eine äußerst nützliche Information zu sein, die einem Entwickler zur Verfügung gestellt werden kann. Für einen Benutzer sieht es nach komplettem Kauderwelsch aus, der überhaupt keinen Nutzen hat. Selbst wenn Sie ihnen etwas anderes sagen, 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.

In Bezug auf die Sicherheit könnten Sie einen Punkt haben, wenn es sich um eine Desktop-Anwendung handelt. In diesem Fall bietet das Drucken eines Stack-Trace nichts, was ein Angreifer noch nicht weiß. In einer Web-App stehen diese Informationen einem Angreifer noch nicht zur Verfügung. Sie legen in der Tat interne Details offen, die einen Angriff um eine Menge erleichtern.

Warum umgehen Sie nicht beide Problembereiche und erhalten automatisch Ausnahmemeldungen? Auf diese Weise müssen Sie sich nicht einmal Sorgen machen, dass Personen keine Fehler melden.

15
Karl Bielefeldt

Schauen Sie sich diese Frage der IT Security SE an. Kurz gesagt, eine Stapelverfolgung kann dem Angreifer mehr Informationen geben, 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 auf die Tatsache stützen, dass Stapelspuren immer verborgen sind, aber das bedeutet auch nicht, dass Sie diese Informationen Angreifern geben sollten.

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

11
Oleksi

Aus den folgenden Gründen können Sie erwägen, keine Stapelverfolgung anzuzeigen.

Sicherheit

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

Benutzererfahrung

Für die beste Erfahrung des Benutzers ist eine Strack-Spur zu viele Informationen. Ja, die richtigen Informationen zu einem Fehlerzustand sollten protokolliert und von einem Techniker 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 eine Stapelverfolgung auf einer Website angezeigt wird, sieht sie 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 Stapelspuren, da dies in einigen Frameworks wie ASP.Net die Standardeinstellung ist.

8
Tom Resing

Kurze Antwort: In einem Extranet oder einer Internetseite ist es sinnvoll, die Stapelverfolgung nicht anzuzeigen. In einem Intranet übertreffen die Vorteile der Anzeige der Stapelverfolgung die Vorteile des Versteckens.

Lange Antwort :

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

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

Ich denke, es gibt keine Notwendigkeit für Beweise. Ist offensichtlich, dass je mehr ein Hacker über Ihre Plattform weiß, desto besser für ihn und dass je weniger ein Hacker über Ihre Plattform weiß, desto besser für Sie.

Auch Unternehmen möchten nicht offenlegen, wie ein Hacker in ihre Systeme eingebrochen ist.

Auf der anderen Seite es ist ein Intranet, und ich denke, dass die Vorteile, sofort zu wissen, was schief gelaufen ist ohne das Durchsuchen einer Protokolldatei von großem Vorteil und Sicherheitsrisiko von Das Anzeigen eines Stacktraces innerhalb der Grenzen Ihres Unternehmens ist nicht so hoch, wie es heißt.

6

In jedem gelieferten Produkt sollte die erwartete Anzahl dieser Art von Fehler Null sein. Der Nutzen dieser Informationen für Kunde ist Null. In beiden Fällen gibt es keinen Grund, eine Stapelverfolgung vorzulegen. Wenn es einen nützlichen Kontext gibt, sollte dieser 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 Ihnen sendet. 99,99% der Zeit werden sie nicht. Sie sollten ein Fehlerberichterstattungssystem installieren, das die Informationen automatisch mit nur einem "OK" vom Kunden übermittelt.

5
ddyer