Bundesamt für Sicherheit in der Informationstechnik

M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen und Web-Services

Verantwortlich für Initiierung: Fachverantwortliche, Verantwortliche der einzelnen Anwendungen

Verantwortlich für Umsetzung: Administrator, Entwickler

Webseiten und Rückantworten von Webanwendungen und Web-Services 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 oder des Web-Service 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 oder des Web-Service ein Fehler auf (zum Beispiel 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 zum Beispiel SQL -Fehlermeldungen einer Datenbank statt einer Meldung "Fehler bei der Überprüfung der Zugangsdaten",
  • Fehlercodes statt zum Beispiel 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 (user enumeration).

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 (zum Beispiel gültiger Benutzername bei falschem Passwort) schließen kann.

Weitere Informationen zur Fehlerbehandlung finden sich in M 4.395 Fehlerbehandlung durch Webanwendungen und Web-Services .

Verhinderung von "WS-Interface Probing"

Wenn Web-Services-Description-Language-( WSDL )-Dateien generiert werden, ist darauf zu achten, dass die verwendeten Tools oder Frameworks keine zusätzlichen und womöglich sicherheitskritischen Informationen in die Dateien schreiben. Deswegen sind die Dateien, bevor sie veröffentlicht werden, zunächst entsprechend zu prüfen. Bei Bedarf müssen die Tools bzw. Frameworks dann so umkonfiguriert werden, dass sie keine sicherheitskritischen Informationen mehr in die WSDL -Dateien schreiben oder die Dateien müssen nachträglich bereinigt werden.

XML -Transportcontainer sollten generell keine Fehlermeldungen mit detaillierten Informationen an Benutzer (potenzielle Angreifer) weitergeben. Die Meldungen sollten so allgemein bzw. generisch gestaltet sein, dass sie keine Informationen über eingesetzte Anwendungen, Frameworks und Versionsnummern enthalten und auch keinen Rückschluss auf diese zulassen.

Sollen Dienste nur von bestimmten, dem Service-Provider bekannten Benutzern gesucht und aufgerufen werden können, bietet es sich an, die WSDL -Dateien bzw. deren Repositories mittels einer vorherigen Nutzerauthentisierung vor direktem und unberechtigtem Zugriff zu schützen.

Vermeidung von sicherheitsrelevanten Kommentaren in ausgelieferten Webseiten oder Web-Service-Antworten

Bei der Entwicklung von Webanwendungen werden möglicherweise Kommentare in den HTML -Code geschrieben. Diese Kommentare können sicherheitsrelevante Informationen (zum Beispiel Todo-Listen, Versionsnummern, Zugangsdaten oder uninterpretierter Quellcode) enthalten, die als HTML -Kommentare in der Webseite vom Benutzer leicht eingesehen werden können. Auch die Rückantworten von Web-Services können Kommentare mit sicherheitsrelevanten Informationen enthalten, beispielsweise Kommentare in XML -Antworten eines SOAP -Dienstes. Aus diesem Grund ist darauf zu achten, dass in den Kommentaren keine sicherheitsrelevanten Informationen enthalten sind. Idealerweise sollten in in den ausgelieferten Webseiten oder Rückantworten einer produktiven Webanwendung oder eines Web-Service keine Kommentare verwendet werden.

Eingeschränkter Zugriff auf Dokumentation

Informationen in der Dokumentation einer Webanwendung oder eines Web-Service (zum Beispiel Dokumente zur Administration der Webanwendung) können einem Angreifer auf potentielle Schwachstellen (zum Beispiel Standardbenutzer nach der Installation) hinweisen und missbraucht werden, um Angriffe vorzubereiten. Daher sollte verzichtbare Dokumentation zur Webanwendung oder zum Web-Service und den zugehörigen Komponenten (zum Beispiel Datenbank) gelöscht werden. Ist die Dokumentation online verfügbar, so sollte ausschließlich der entsprechende Adressatenkreis darauf zugreifen können. Beispielsweise sollte die Dokumentation zur Administration einer Webanwendung oder eines Web-Service nicht aus dem Internet heraus erreichbar sein.

Löschen nicht benötigter Dateien

Im laufenden Betrieb einer Webanwendung oder eines Web-Service fallen häufig Dateien an, die nicht für den produktiven Betrieb benötigt werden (zum Beispiel temporäre Dateien, oder Backup-Dateien). Diese Dateien können sicherheitskritische Informationen beinhalten (zum Beispiel Test-Ergebnisse) oder Funktionen anbieten (zum Beispiel 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 (zum Beispiel *.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.

Versionsverwaltungssysteme legen zumeist Dateien oder Ordnerstrukturen für die von ihnen verwalteten Objekte an (zum Beispiel Ordner wie .svn oder .git). Diese Dateien oder Ordner enthalten häufig detaillierte Informationen zu den verwalteten Projekten und ermöglichen unter Umständen einen kompletten Zugriff auf den Quellcode. Aus diesem Grund sollten Anwendungen oder Anwendungskomponenten grundsätzlich nicht über die Versionsverwaltung auf Produktivsysteme aufgespielt werden. Zumindest sollte der Zugriff auf von der Versionsverwaltungssoftware angelegte Dateien und Ordner blockiert werden.

Aus den genannten Gründen sind alle Dateien zu löschen, die für den produktiven Betrieb 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 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 (zum Beispiel Pfade) der Webanwendung zu ignorieren. Auf diese Weise können schützenswerte Informationen von der Indizierung in der Suchmaschine ausgenommen werden. Die vertraulichen Ressourcen (zum Beispiel 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.

Schutz vor Directory-Traversal-Angriffen

Ein Zugriff auf Ressourcen darf nur mit den dafür benötigten Rechten und nach einer vorausgegangenen Authentisierung erfolgen. Demzufolge sind geeignete Authentisierungsmechanismen zu implementieren sowie strikte Zugriffsregeln (Policies) zu definieren und umzusetzen. Zusätzlich kann ein Intrusion-Detection-System eingesetzt werden, das Directory-Traversal-Angriffe erkennt.

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 zum Beispiel in HTTP -Headern oder in Kommentaren im HTML -Quelltext der ausgelieferten Webseiten, aber auch in XML - oder JSON -Antworten von Web-Services enthalten sein. Auf der Grundlage dieser Angaben kann ein Angreifer gezielt nach bekannten Schwachstellen des Produkts suchen und über diese die Webanwendung oder den Web-Service angreifen. Daher sollten Angaben zu verwendeten Produkten und Versionen vermieden werden (zum Beispiel 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 oder des Web-Service veröffentlicht werden.

Prüffragen:

  • Werden ausschließlich Informationen veröffentlicht, die für den Betrieb oder die Nutzung der Webanwendung oder des Web-Service erforderlich sind?

  • Werden von der Webanwendung oder dem Web-Service ausschließlich neutrale Fehlermeldungen ausgegeben und sind diese im Quelltext identisch?

  • Werden sicherheitsrelevante Informationen in Webseiten (zum Beispiel in Kommentaren) oder Web-Service Antworten vor der Auslieferung an die Benutzer gelöscht?

  • Ist nur dem entsprechenden Adressatenkreis der Zugriff auf sicherheitsrelevante Dokumentation der Webanwendung oder des Web-Service möglich?

  • Werden vor der produktiven Inbetriebnahme alle Dateien gelöscht, die nicht für den Betrieb der Webanwendung oder des Web-Service 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 enthalten?

  • Sind die WSDL-Dateien/Repositories mittels geeigneter Authentisierungsmechanismen geschützt?

  • Sind für den Zugriff auf Ressourcen geeignete Authentisierungsmechanismen implementiert und strikte Zugriffsregeln festgelegt?

Stand: 15. EL Stand 2016

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK