it-swarm.com.de

Ist es eine gute Praxis, dem Benutzer 403 nicht autorisierte Zugriffsfehler anzuzeigen?

Immer wenn wir eine 403-Seite mit verbotenen Zugriffsfehlern sehen, denken wir, wir haben einen Ort gefunden, an dem geheime oder private Daten vorhanden sind. An diesem Punkt wissen die Bösen, dass dies von Interesse sein könnte, und beginnen zu prüfen, ob sie etwas tun können, um Zugriff auf diese geheimen Daten zu erhalten.

Ist es also gut, diesen Fehler anzuzeigen oder einfach an einen anderen Ort umzuleiten?

Bearbeiten

Ich denke, mit Fehlern umzugehen ist, auf eine separate Anmeldeseite umzuleiten, um auf diese bestimmte Ressource zuzugreifen. Aber in diesem Fall auch, wenn ich einfach nicht möchte, dass jemand (möglicherweise sogar Administrator) über meine Anwendung Zugriff auf diese Ressource hat. Offcourse-Administrator kann im Backend auf andere Weise auf dieselbe Ressource zugreifen.

28
ThankYouSRT

In der Produktionsumgebung möchten Sie normalerweise so wenig Informationen wie möglich offenlegen. Zu diesem Zweck sollten generische Fehlercodes angezeigt werden:

  • Fehler 4 für Client-bezogene Fehler: Ungültige Anforderung, Authentifizierung erforderlich usw.
  • Fehler 5 für serverbezogene Fehler: Datenbank ausgefallen, Standort wegen Wartungsarbeiten ausgefallen usw.

Im Idealfall sollten Sie sich nicht für die von Ihrem Webserver bereitgestellten Standardfehlerseiten entscheiden. Sie können entweder eigene Fehlerseiten erstellen oder die Standardfehlerseiten so bearbeiten, dass alle Informationen ausgeblendet werden, die von einem Angreifer verwendet werden könnten. Hier ist beispielsweise ein Fehler von einem unserer Server beim Zugriff auf eine kennwortgeschützte URL:

enter image description here

Darüber hinaus handelt es sich um ein reines Usability-Problem, das stark von der Groß- und Kleinschreibung abhängt. Sollten Sie Benutzer nicht zur Startseite weiterleiten? Sind diese Bereiche passwortgeschützt? Sollten Sie ein Anmeldeformular anzeigen? Oder möchten Sie einfach die allgemeine Fehlermeldung mit dem Stil Ihrer Site anzeigen?

Hier ist ein Beispiel für eine Fehlerseite auf unserer Website (Security.StackExchange)

enter image description here

10
Adi

Wie @Adnan sagt, möchten Sie in jeder Produktionsumgebung den Informationsverlust begrenzen. Eine Weiterleitung kann auch für einen Angreifer nützlich sein.

Ich würde die Empfehlung etwas weiter gehen und sagen, Sie sollten nicht nur die Fehlertypen einschränken, sondern auch immer nur angepasste Fehlerseiten an den Endbenutzer liefern.

Standardmäßig enthalten 400 oder 500 Seiten häufig eine Fülle von Informationen über den Fehler. Dies ist für einen Angreifer sehr nützlich. Er kann herausfinden, welche Software ausgeführt wird, welcher Webserver, welches Betriebssystem usw.

Die allgemeine Empfehlung in einem Fehlerkontext lautet daher, dem Benutzer eine angepasste Seite bereitzustellen, die einen Fehler bestätigt, aber nichts preisgibt, zum Beispiel:

enter image description here

Intern sollten alle Fehler protokolliert werden, damit sie behoben werden können.

9
Rory Alsop

Ja, es bedeutet lediglich, dass die Authentifizierung erfolgreich war, das Konto jedoch nicht zum Anzeigen dieser Ressource berechtigt ist. Per RFC2616 könnte stattdessen ein HTTP 404 verwendet werden. Ich würde jedoch davon abraten, da die Rückgabe eines 403 die folgenden Vorteile bietet:

  1. Bei Systemen mit mehreren Konten (d. H. Active Directory) bietet dies dem Benutzer die erforderlichen Informationen, dass er sich möglicherweise mit dem falschen Konto angemeldet hat und es mit einem anderen versuchen sollte.
  2. Wenn der Benutzer zu Recht Zugriff benötigt, kann das Helpdesk-Ticket schnell verarbeitet werden, da er eine 403 erhält.

In Ihrem Szenario haben sich die "bösen Jungs" bereits erfolgreich angemeldet. Hoffentlich ist der Autorisierungsprozess robust genug, um weiteren Schaden zu verhindern (d. H. Verwenden Sie keine Abfragezeichenfolgen).

Während viele das Deaktivieren detaillierter Fehlermeldungen kommentiert haben, stimme ich zu, dass dies eine bewährte Methode ist. Ein 403 unterscheidet sich jedoch stark von einem Serverfehler wie einem HTTP 500, bei dem interessante Informationen auf dem Bildschirm gedruckt werden. Wiederum bedeutet ein 403 nur, dass Sie nach erfolgreicher Anmeldung nicht berechtigt sind, eine bestimmte Ressource anzuzeigen. Geben Sie also weiterhin einen 403 zurück, geben Sie jedoch keine ausführlichen Diagnoseinformationen an.

Wenn es sich um eine äußerst sensible Ressource handelt, sollten Sie sie trennen und eine Dual-Faktor-Authentifizierung erfordern. Dies bietet zusätzliche Sicherheit, dass die Person wirklich der ist, für den sie sich beim Zugriff auf die geschützte Ressource ausgibt.

6
user2320464

Um Ihre erste Frage zu beantworten, ist es nicht gut, diesen Fehler dem Endbenutzer anzuzeigen.

Das Anzeigen einer Standardfehlerseite mit den genauen technischen Details ist keine gute Vorgehensweise. Es gibt sowohl Sicherheits- als auch Benutzererfahrungsprobleme.

Wenn der Benutzer eine nicht technische Person ist, kann diese Art von Fehlermeldungen ihn mit all den technischen Dingen sehr ärgern. Er wird nicht wissen, was er tun soll, um den Fehler zu lösen, den er nicht versteht.

Wenn der Benutzer jedoch eine technische Person ist (sagen wir eine schlechte), besteht für ihn die Möglichkeit, einen Einblick oder eine Gesamtidee Ihrer Sicherheitsstruktur Ihrer Anwendung zu erhalten. Es besteht eine faire Chance, dass er entlarvt wird, wenn er die Sicherheitsmuster in Ihrer Anwendung herausfindet, da die Angriffe, die er versucht, Ihre Anwendung zu brechen, genau oder zumindest ein bisschen genauer sind =.

Um Ihre zweite Frage zu beantworten, scheint es keine gute benutzerfreundliche Idee zu sein, auf eine andere Seite umzuleiten.

Wenn der Benutzer versucht, auf etwas zuzugreifen, und er direkt zur Startseite oder einer anderen Seite weitergeleitet wird, wird dies die Benutzerfreundlichkeit beeinträchtigen und das Interesse des Benutzers an Ihrer Anwendung. Wenn Sie ihn wirklich irgendwo umleiten möchten, zeigen Sie ihm eine ordentliche angepasste Nachricht und leiten Sie ihn dann weiter. Damit er zumindest weiß, was passiert.

Fehlerbehandlung ist die Lösung für Ihr Problem. Denken Sie immer in der Perspektive des Benutzers, wenn Sie die Fehlermeldungen vorbereiten. Show passt Fehlermeldungen an, die der Benutzer leicht verstehen kann, und legt auch keine Sicherheitsstruktur Ihrer Anwendung offen.

Fazit - Jede Art von Fehler muss behandelt und angepasst sein, bevor der Benutzer informiert wird.

4

Ist es eine gute Praxis? Es hängt davon ab, ob. Ich bin damit einverstanden, dass Sie wahrscheinlich nicht nur die Standardseite an den Benutzer senden möchten. Dies beeinträchtigt die Benutzerfreundlichkeit und kann einem Angreifer zu viele Informationen liefern, wenn technische Details vorliegen.

Was ist jedoch mit dem Senden von 403-Fehlern im Allgemeinen? Hier bin ich weniger davon überzeugt, dass es im Allgemeinen eine schlechte Idee ist, und die größere Frage ist, was los ist oder warum der 403-Fehler auftritt.

Wenn ich einen 403-Fehler mit einer Standardfehlerseite sehe oder insbesondere wenn ich noch nicht einmal angemeldet bin, schreit dies "inkompetenter Administrator" und scheint daher nicht so sehr zum Angriff einzuladen, sondern vielmehr zu dem, was es über Ihre Website verrät, als vielmehr zu dem, was es ist enthüllt über Ihre Administratoren.

Angenommen, ich bin angemeldet. Ich wurde authentifiziert. Gibt es einen Grund, wenn ich versuche, auf eine Ressource zuzugreifen, für die ich nicht berechtigt bin, anzuzeigen, dass sie etwas anderes als eine Fehlermeldung "403 Access Denied" zurückgeben soll? Durch die Rückgabe des Fehlercodes kann dies auf der Clientseite programmgesteuert behandelt werden. Dies ist eine wichtige Überlegung bei Dingen wie Webdiensten.

Dies sollte natürlich niemals passieren, wenn Sie versuchen, etwas zu tun, das in der Benutzeroberfläche angezeigt wird. Aber als zusätzliche Verteidigungsebene und Möglichkeit zur Fehlerbehandlung sehe ich in diesem Fall nichts Falsches daran, den Fehlercode zurückzugeben, da es Ursachen geben kann (wieder kommen Webdienste in den Sinn), bei denen die Übergabe des Fehlercodes erfolgt der beste Weg nach vorne.

In diesem Sinne sehe ich einige Dinge, die unbeschadet betrachtet werden müssen:

Welche Informationen sind durchgesickert, die einem Angreifer helfen können? Welche Informationen sollten mit der Fehlermeldung versehen werden?

Im Allgemeinen protokollieren wir mit LedgerSMB ausführlich, aber alles, was den Zugriff verweigert, ist eine sehr kurze Nachricht auf der Client-Seite. Auf diese Weise kann der Administrator sehen, was gerade passiert, nicht jedoch der Benutzer.

Was muss der Client mindestens wissen, um den Fehler zu behandeln?

Normalerweise, IMO, wurde nur dieser Zugriff verweigert, obwohl er angemeldet war. Der 403 kann hier hilfreich sein, aber Sie möchten nicht viel mehr senden.

Welche anderen Bedenken haben Sie?

Viele Dinge hängen vom Bedrohungsmodell ab. Das Bedrohungsmodell einer kundenorientierten Webanwendung unterscheidet sich stark von einer Business-Webanwendung, und diese unterscheiden sich von einem Abonnement-Webdienst. Sie müssen wissen, was Sie schützen und vor was, bevor Sie weiter gehen.

2
Chris Travers

Wenn Sie sich den Kontext Ihrer Frage ansehen, scheint es sich um eine Verwaltungsseite zu handeln, für deren Zugriff eine Anmeldung erforderlich ist. Sie befürchten, dass durch die Anzeige eines 403-Fehlers für nicht autorisierte Benutzer jeder, der die URL errät, weiß, dass die Seite vorhanden ist, auf die jedoch nicht zugegriffen werden kann.

Offensichtlich sollte die Fehlerseite, falls vorhanden, keine Informationen wie Ihre Serverarchitektur und -version enthalten. Ich werde diese grundlegenden Dinge nicht noch einmal wiederholen. Hier gibt es einige Optionen. Schauen wir uns die verschiedenen Optionen an:

Eine Weiterleitung zur Administrator-Anmeldeseite:

Dies ist aus Sicht des Administrators nützlich. Möglicherweise ist ein Sitzungszeitlimit aufgetreten. Der Administrator, der auf den Link zu dieser Seite geklickt hat, wird direkt zur Anmeldeseite weitergeleitet, um den privilegierten Zugriff fortzusetzen. Andere werden ebenfalls auf die Anmeldeseite umgeleitet. Wenn es sich um ein verstecktes Login handelt, entspricht dies dem Zeigen der Tür für einen Hacker. In diesem Fall würde ich dringend von einer Weiterleitung abraten.

Anzeige 403 Fehler:

Dieser Fehler ist eindeutig. Sowohl der Administrator als auch der Benutzer können verstehen, dass ihr Zugriff verweigert wird, weil sie nicht autorisiert sind. Für den Administrator kann dies an einem Sitzungszeitlimit liegen oder wenn er von einer nicht erkannten IP-Adresse auf die Seite zugreift. Nun kann ein entschlossener Hacker auch durch Ausprobieren auf dieser Seite. Die Frage ist, sollten Sie sich darüber Sorgen machen? Wenn die Seite selbst keine Benutzereingaben akzeptiert und Sie sicher sind, dass der Code sauber und gut geschrieben ist, sollten Sie dies nicht tun.

Anzeige 404 Fehler:

Wenn Sie einen 404-Fehler anzeigen, führen Sie tatsächlich ein Sicherheit durch Dunkelheit aus. Es besteht kein Zweifel an einem Sicherheitsgewinn, aber Sie sollten sich nicht nur darauf verlassen. Ein Benutzer würde normalerweise weitermachen, wenn ein Fehler in der 404-Datei nicht gefunden wird. Hier gibt es einen Kompromiss, da Ihr Administrator möglicherweise verwirrt ist, wenn ein anderer Fehlercode angezeigt wird als erwartet. Wenn Ihr Administrator dies weiß, sollte dies kein großes Problem sein.

Sie stellen diese Frage, weil Sie sich Sorgen machen. Um beruhigt zu sein, würde ich mich für die dritte Option entscheiden. Letztendlich liegt es jedoch an Ihnen, basierend auf den Sicherheitsanforderungen Ihrer Webanwendung zu entscheiden.

2