API, die eine Java-Ausnahme zurückgibt. Sicher?

Oct 23 2020

Ich wollte nur fragen, ob meine Bedenken hier berechtigt sind.

Mir ist bekannt, dass es für die API nicht sicher ist, einen Stack-Trace zurückzugeben. Ich habe eine ähnliche, aber weniger ungeheure Situation, die ich zu beurteilen versuche.

Gibt es auch einen Standard für das Packen von Java-Ausnahmen in eine 500-Antwort? Senden Sie beispielsweise Dinge wie "DataIntegrityViolationException", "NullPointerException" usw. zurück, jedoch ohne den Stack-Trace.

Anders ausgedrückt, wenn eine nicht behandelte Ausnahme auftritt, wird der Ausnahmenname in der 500-Antwort zurückgesendet. Es gibt keine Stapelverfolgung, aber wir können auf der Clientseite schließen, ob beispielsweise die Anforderung versucht hat, die Datenbank auf ungültige Weise zu ändern.

Ich warne derzeit mein Team davor und sage ihnen, dass sie ihre Serverantworten "auf die Whitelist" setzen sollen (dh nur Inhalte senden, wenn Sie einen bewussten Grund dafür haben). Ich wollte nur wissen, ob ich ihre Zeit damit verschwende.

Ist das eine gute Idee?

Oder sollte es allgemeiner sein?

Antworten

1 schroeder Oct 28 2020 at 00:05

Der Standard bei der Fehlerbehandlung für den Kunden besteht darin, nichts über das Innenleben preiszugeben und nur das bereitzustellen, was für den Benutzer nützlich ist , um erfolgreich zu sein.

Der Inhalt der Java-Fehlermeldung hilft dem Benutzer nicht weiter. Am Ende legen Sie Ihre Codelogik offen, die von einem böswilligen Benutzer gegen Sie verwendet werden kann.

In den Beispielen von OWASP wird lediglich angegeben, dass ein Fehler vorliegt. Und das ist der Standard. Alle darüber hinausgehenden Informationen müssen begründet sein.