M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen
Verantwortlich für Initiierung: Fachverantwortliche, Verantwortliche der einzelnen Anwendungen
Verantwortlich für Umsetzung: Entwickler, Administrator
Webseiten und Rückantworten der Webanwendung können sicherheitsrelevante Informationen beinhalten, mit deren Hilfe Angreifer Sicherheitsmechanismen umgehen und Schwachstellen ausnutzen können. Daher dürfen keine sicherheitsrelevanten Informationen angezeigt werden, die nicht zwingend für den Betrieb und die Nutzung der Webanwendung notwendig sind.
Die folgenden Beispiele verdeutlichen, welche Informationen sicherheitsrelevante Hinweise enthalten können und wie verhindert werden kann, dass diese offengelegt werden.
Keine sicherheitsrelevanten Informationen in Fehlermeldungen
Tritt bei der Bedienung der Webanwendung ein Fehler auf ( z. B. Zugriffsfehler), sollten dem Benutzer neutrale Fehlermeldungen übermittelt werden. Die Fehlermeldungen dürfen keine direkten Rückschlüsse auf eingesetzte Techniken, Sicherheitsmechanismen und Zustände der Webanwendung ermöglichen.
Die folgenden Beispiele zeigen Informationen, die nicht in Fehlermeldungen enthalten sein sollten:
- Stacktraces und Debugging-Informationen,
- Meldungen wie "Benutzername ungültig" oder "Passwort ungültig" (anstelle von allgemeinen Fehlermeldungen wie "Benutzername oder Passwort ungültig"),
- von Hintergrundsystemen weitergereichte Fehlermeldungen wie z. B. SQL -Fehlermeldungen einer Datenbank statt einer Meldung "Fehler bei der Überprüfung der Zugangsdaten",
- Fehlercodes statt z. B. der Meldung "Ein Fehler ist aufgetreten".
Im Fall einer fehlgeschlagenen Authentisierung sollte beispielsweise unabhängig von der Gültigkeit des Benutzernamens stets eine allgemeingültige Meldung wie "Falsche oder ungültige Zugangsdaten" ausgegeben werden, damit ein Angreifer nicht auf die Existenz von Benutzerkonten rückschließen kann.
Grundsätzlich kann unterschiedlicher HTML -Code zur gleichen Ausgabe im Webbrowser führen. Beispielsweise werden zwei HTML-Seiten mit einer unterschiedlichen Anzahl von Leerzeichen im Browser gleich dargestellt, obwohl sie sich im HTML-Code unterscheiden. Es ist daher darauf zu achten, dass die Fehlermeldungen nicht nur in der Darstellung im Browser, sondern auch im HTML-Code identisch sind. Hiermit soll verhindert werden, dass ein Angreifer aufgrund eines veränderten HTML-Codes auf die Gültigkeit von Teil-Eingaben (z. B. gültiger Benutzername bei falschem Passwort) schließen kann.
Weitere Informationen zur Fehlerbehandlung finden sich in M 4.395 Fehlerbehandlung durch Webanwendungen .
Vermeidung von sicherheitsrelevanten Kommentaren in ausgelieferten Webseiten
Bei der Entwicklung von Webanwendungen werden möglicherweise Kommentare in den HTML-Code geschrieben. Diese Kommentare können sicherheitsrelevante Informationen (z. B. Todo-Listen, Versionsnummern, Zugangsdaten oder uninterpretierter Quellcode) enthalten, die als HTML-Kommentare in der Webseite vom Benutzer leicht eingesehen werden können. Aus diesem Grund ist darauf zu achten, dass in den Kommentaren keine sicherheitsrelevanten Informationen enthalten sind. Idealerweise sollten in den Quelltexten und im HTML-Code einer produktiven Webanwendung keine Kommentaren verwendet werden.
Eingeschränkter Zugriff auf Dokumentation
Informationen in der Dokumentation einer Webanwendung (z. B. Dokumente zur Administration der Webanwendung) können einem Angreifer auf potentielle Schwachstellen (z. B. Standardbenutzer nach der Installation) hinweisen und missbraucht werden, um Angriffe vorzubereiten. Daher sollte verzichtbare Dokumentation zur Webanwendung und den zugehörigen Komponenten (z. B. Datenbank) gelöscht werden. Ist die Dokumentation der Webanwendung online verfügbar, so sollte ausschließlich der entsprechende Adressatenkreis darauf zugreifen können. Beispielsweise sollte die Dokumentation zur Administration einer Webanwendung nicht aus dem Internet heraus erreichbar sein.
Löschen nicht benötigter Dateien
Im laufenden Betrieb einer Webanwendung fallen häufig Dateien an, die nicht für den produktiven Betrieb benötigt werden (z. B. temporäre Dateien, oder Backup-Dateien). Diese Dateien können sicherheitskritische Informationen beinhalten (z. B. Test-Ergebnisse) oder Funktionen anbieten (z. B. Testwerkzeuge zur Ermittlung von Versionsnummern der eingesetzten Bibliotheken), die für Angriffe auf die Webanwendung genutzt werden können.
Darüber hinaus ist zu beachten, dass insbesondere bei temporären Dateien oder Backup-Dateien häufig andere Dateiendungen (z. B. *.bak-Dateien als Sicherheitskopien eines Editors) verwendet werden. Werden diese Dateien vom Webserver abgerufen, wäre es möglich, dass die Dateien aufgrund der unbekannten Dateiendung nicht mehr interpretiert werden und stattdessen der Quelltext der Webanwendung ausgeliefert wird.
Daher sind alle Dateien zu löschen, die für den produktiven Betrieb der Webanwendung nicht benötigt werden. Darüber hinaus sollte regelmäßig kontrolliert werden, ob neue Dateien angefallen sind und ob diese gelöscht werden können. Ist dies nicht möglich, kann der Webanwendung der Zugriff auf diese Dateien gesperrt werden.
Sichere Erfassung durch externe Suchmaschinen
Suchmaschinen setzen sogenannte Agenten (auch Robots oder Crawler genannt) ein, um neue oder geänderte Inhalte im Netz zu indizieren. Diese Agenten können durch die Datei robots.txt im Wurzelverzeichnis der Webanwendung instruiert werden, ausgewiesene Ressourcen (z. B. Pfade) der Webanwendung zu ignorieren. Auf diese Weise können schützenswerte Informationen von der Indizierung in der Suchmaschine ausgenommen werden. Die vertraulichen Ressourcen (z. B. Verzeichnis-Pfade) sollten in der Datei robots.txt unter der Direktive "Disallow" aufgeführt werden. So werden die Agenten veranlasst, die gelisteten Ressourcen nicht zu indizieren.
Damit die Einträge in der Datei robots.txt einem Angreifer keine Hinweise auf sicherheitskritische Ressourcen der Webanwendung geben, sollten alle zu schützenden Verzeichnisse nach Möglichkeit in einem gesonderten Verzeichnis der Webanwendung zusammengefasst werden. Ausschließlich dieses Verzeichnis sollte in die Datei robots.txt eingetragen werden, sodass diese keine internen Verzeichnisstrukturen mit sicherheitsrelevanten Informationen enthält.
Vermeidung von Produkt- und Versionsangaben
Häufig enthalten Antworten und Ausgaben der einzelnen Komponenten der Webanwendung Angaben zu Produktnamen und Versionsnummern. Diese Informationen können z. B. in HTTP -Headern oder in Kommentaren im HTML-Quelltext der ausgelieferten Webseiten enthalten sein. Auf der Grundlage dieser Angaben kann ein Angreifer gezielt nach bekannten Schwachstellen des Produkts suchen und über diese die Webanwendung angreifen. Daher sollten Angaben zu verwendeten Produkten und Versionen vermieden werden (z. B. Applikationsframework, Webserver).
Verzicht auf absolute Pfadangaben
Absolute Pfadangaben ermöglichen oft Rückschlüsse auf die interne Struktur und den Aufbau der Webanwendung. So kann beispielsweise der Speicherort schützenswerter Informationen ermittelt werden. Daher sollten nach Möglichkeit keine absoluten Pfadangaben der Webanwendung veröffentlicht werden.
Prüffragen:
- Werden ausschließlich Informationen veröffentlicht, die für den Betrieb oder die Nutzung der Webanwendung erforderlich sind?
- Gibt die Webanwendung dem Benutzer ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch?
- Werden sicherheitsrelevante Informationen in Webseiten (z. B. in Kommentaren) vor der Auslieferung durch die Webanwendung an die Benutzer gelöscht?
- Ist nur dem entsprechenden Adressatenkreis der Zugriff auf Dokumentation der Webanwendung möglich?
- Werden vor der produktiven Inbetriebnahme der Webanwendung alle Dateien gelöscht, die nicht für den Betrieb der Webanwendung notwendig sind, und wird eine entsprechende Prüfung auf nicht benötigte Dateien regelmäßig durchgeführt?
- Enthält die Datei robots.txt ausschließlich URLs, die keine sicherheitsrelevanten Informationen der Webanwendung enthalten?