Coders Conquer Security: Share & Learn Serie – Informationslecks

"Loose lips sink ships" war ein im Zweiten Weltkrieg in den USA populärer Spruch. In Großbritannien hieß es: "Careless talk costs lives." Die Kernaussage war, dass unbedachtes Reden über sensible Informationen von Spionen belauscht werden und schwerwiegende Folgen haben konnte.

Dasselbe Prinzip gilt für die Entwicklung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann dies Angreifern das Eindringen erleichtern.

In diesem Beitrag erfahren Sie, was Informationspreisgabe ist, warum sie gefährlich ist und wie Sie sie verhindern können.

Informationspreisgabe verstehen

Informationspreisgabe bezeichnet Webanwendungen, die interne Informationen an Unbefugte weitergeben. Dies kann auch die Offenlegung sensibler Kundendaten über Protokolldateien oder die Benutzeroberfläche umfassen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Nutzer anzugreifen.

Oft besteht der erste Schritt eines Angreifers darin, einen Fehler in Ihrer Anwendung zu provozieren. Mangelhafte Fehlerbehandlung und Konfiguration der Webanwendung führen zu Informationspreisgabe durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler in Ihrer Anwendung auslöst? Wenn eine technische Fehlermeldung erscheint, die Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können verraten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers läuft.

Die Offenlegung sensibler Informationen kann auch auf andere Weise erfolgen. Gibt es versteckte Felder in einem Formular, die sensible Daten enthalten? Angreifer können einfach den Quelltext der Seite aufrufen und die Werte einsehen.

Kurz gesagt: Informationspreisgabe tritt auf, wenn Informationen, die nur für einen begrenzten Personenkreis bestimmt sind, zu leicht zugänglich gemacht werden.

Warum Informationspreisgabe gefährlich ist

Was kann ein Angreifer mit den von der Anwendung preisgegebenen Informationen anfangen? Wenn es sich um sensible Daten handelt, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies kann zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen.

Wenn ein Angreifer Fehlermeldungen nutzt, um Informationen über eine Anwendung zu erhalten, könnten diese für einen späteren Angriff verwendet werden. Tatsächlich enthält der OWASP Testing Guide einen ganzen Abschnitt über Informationsbeschaffung.

Der OWASP Testing Guide empfiehlt, Suchmaschinen zu nutzen, um herauszufinden, welche Informationen über Ihre Website ungewollt öffentlich sind. Sind beispielsweise Ihre Verwaltungsseiten für Suchmaschinen zugänglich? Verwenden Sie die robots.txt-Datei, um Suchmaschinen anzuweisen, bestimmte Seiten nicht zu indexieren. Gleichzeitig kann die robots.txt-Datei selbst Informationen preisgeben. Sensible URLs können manchmal in der robots.txt-Datei stehen. Angreifer laden die Datei herunter und beginnen, die Verzeichnisstruktur der Website zu analysieren.

Google bietet erweiterte Suchoptionen, die eine tiefgehende Untersuchung von Websites ermöglichen. Sie können beispielsweise eine bestimmte Website mit der Syntax "site:<domain>" durchsuchen. Sie können zwischengespeicherte Seiten einsehen, die möglicherweise gelöscht wurden, aber noch in einem Cache aus einem früheren Indexierungsvorgang vorhanden sind. Die Nutzung verschiedener Suchmaschinen wie Bing und DuckDuckGo kann unterschiedliche Ergebnisse liefern. Testen Sie daher bei jeder Suchmaschine, was über Ihre Webanwendung preisgegeben wird.

HTTP-Header, Website-Banner und sogar Kommentare im HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern verraten. Angreifer können diese Informationen nutzen, um Exploits für diese spezifischen Versionen zu finden. Stellen Sie sicher, dass Sie alle Orte kennen, an denen Angreifer Informationen über Sie finden könnten, und wissen, wie Sie diese angemessen verbergen.

Informationspreisgabe verhindern

Informationspreisgabe ist oft ein Problem der Konfiguration von Webanwendungen. Viele Anwendungsserver geben standardmäßig Stack-Traces in Fehlermeldungen aus. Stellen Sie sicher, dass Sie diese Einstellung für Produktionsanwendungen ändern, um auf eine allgemeine Fehlerseite umzuleiten, während der Fehler zur Fehlerbehebung protokolliert wird. Detaillierte Fehlermeldungen sollten niemals an den Browser des Benutzers zurückgegeben werden.

Wenn Sie Dateien benötigen, die sensible Informationen enthalten, stellen Sie durch eine ordnungsgemäße Zugriffskontrolle sicher, dass nur die Anwendung selbst darauf zugreifen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Stammverzeichnisses. Dies verhindert, dass Angreifer über den Browser mittels eines Directory-Traversal-Angriffs auf die Datei zugreifen können.

Protokolle können bei falscher Konfiguration Informationen preisgeben. Protokollieren Sie bei Fehlern niemals sensible Daten wie Passwörter, Session-Token oder personenbezogene Daten (PII). Sollte ein Angreifer Zugriff auf Logdateien erhalten, fände er dort eine wahre Fundgrube an vertraulichen Informationen. Protokollieren Sie nur das Nötigste – in der Regel eine Benutzerkennung, eine detaillierte Fehlermeldung sowie gegebenenfalls die Methode oder den Vorgang, bei dem der Fehler auftrat. Gehen Sie davon aus, dass Logdateien nicht geheim sind, dann kommen Sie gar nicht erst in Versuchung, sensible Daten darin abzulegen.

Versenken Sie nicht Ihre Webanwendungen

Könnten Sie durch ein Gespräch mit einem Freund tatsächlich Informationen preisgegeben haben, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Genau das ist die Lektion hinter dem Spruch: „Vorsicht bei der Wortwahl, sonst droht die Gefahr.“

Genauso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung nach außen zu tragen. Es gibt keinen Grund, vollständige Kreditkartennummern oder Passwörter anzuzeigen. Es gibt keinen Grund, PII-Daten in Logdateien zu speichern. Also lassen Sie es bleiben. Sehen Sie sich unsere Lernressourcen an, um mehr über Informationslecks zu erfahren.

Bewahren Sie die internen Abläufe Ihrer Anwendungen dort auf, wo sie hingehören. Versenken Sie nicht Ihre Webanwendungen.

Glauben Sie, dass Sie Informationslecks sofort stoppen können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]