Blog

Coders Conquer Security: Share & Learn Series - Information Exposure

Jaap Karan Singh
Veröffentlicht am 02. Mai 2019

"Lose Lippen versenken Schiffe" war eine Redewendung, die in den Vereinigten Staaten während des Zweiten Weltkriegs populär wurde. In Großbritannien hörte man "Careless talk costs lives". Die Hauptaussage des Sprichworts war, dass unvorsichtiges Sprechen über sensible Informationen von Spionen belauscht werden und zu ernsten Konsequenzen führen konnte.

Das gleiche Prinzip gilt für die Erstellung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher sein, in sie einzubrechen.

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

Verstehen der Informationsexposition

Informationsexposition bezieht sich auf Webanwendungen, die interne Informationen für Personen offenlegen, die sie nicht sehen sollten. Es kann sich auch auf die Offenlegung sensibler Kundeninformationen über Protokolldateien oder die Benutzeroberfläche beziehen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Benutzer anzugreifen.

Oft ist der erste Schritt für einen Angreifer der Versuch, einen Fehler innerhalb Ihrer Anwendung zu erzeugen. Schlechte Fehlerbehandlung und Webanwendungskonfiguration führt zur Offenlegung von Informationen durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler innerhalb Ihrer Anwendung erzeugt? Wenn eine technische Fehlermeldung erscheint, die technische Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können beinhalten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers Sie einsetzen.

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

Kurz gesagt: Informationsexposition tritt auf, wenn Informationen, die Ihre Benutzer nur auf einer Need-to-know-Basis kennen sollten, zu leicht zugänglich gemacht werden.

Verstehen Sie, warum die Exposition gegenüber Informationen gefährlich ist

Was kann ein Angreifer mit den von der Anwendung offengelegten Informationen tun? Wenn die Informationen sensibler Natur sind, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies könnte zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen

Wenn ein Angreifer Fehlermeldungen verwendet, um Informationen über eine Anwendung zu erhalten, könnten diese Informationen in einem zukünftigen Angriff verwendet werden. Tatsächlich gibt es im OWASP Testing Guide einen ganzen Abschnitt über das Sammeln von Informationen.

Der OWASP Testing Guide ermutigt die Verwendung von Suchmaschinen, um Informationen über Ihre Website herauszufinden, die Sie vielleicht nicht beabsichtigen. Sind zum Beispiel Ihre administrativen Seiten für Suchmaschinen zugänglich? Verwenden Sie die Datei robots.txt, um Suchmaschinen mitzuteilen, dass sie bestimmte Seiten nicht indizieren sollen. Gleichzeitig kann die robots.txt-Datei aber auch Informationen preisgeben. Sensible URLs können sich zuweilen in der robots.txt-Datei befinden. Die Angreifer ziehen die Datei herunter und beginnen, einen Teil der Verzeichnisstruktur der Website zu erfahren.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP-Header, Website-Banner und sogar Kommentare in HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern preisgeben. Angreifer können diese Informationen nutzen, um Exploits zu finden, die gegen diese spezifischen Versionen eingesetzt werden können. Vergewissern Sie sich, dass Sie all die verschiedenen Stellen kennen, an denen Angreifer Ihre Informationen finden könnten, und wie Sie sie angemessen verbergen können.

Beseitigen Sie die Informationsaussetzung

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

Wenn Sie für die Anwendung notwendige Dateien haben, die sensible Informationen enthalten, stellen Sie sicher, dass eine angemessene Zugriffskontrolle gewährleistet, dass nur die Anwendung selbst diese lesen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Root-Verzeichnisses. Dies verhindert, dass Angreifer mit dem Browser über einen Directory-Traversal-Angriff zu der Datei navigieren können.

Protokolle können zum Sammeln von Informationen verwendet werden, wenn sie nicht korrekt konfiguriert sind. Wenn ein Fehler auftritt, protokollieren Sie keine sensiblen Informationen wie Passwörter, Sitzungs-Tokens oder persönlich identifizierbare Informationen (PII). Wenn ein Angreifer Zugriff auf Protokolldateien erhalten könnte, würde er eine Fundgrube an sensiblen Informationen finden, die er stehlen könnte. Protokollieren Sie nicht mehr als nötig, was in der Regel eine Kontokennung, eine detaillierte Fehlermeldung und vielleicht die Methode, in der der Fehler aufgetreten ist, oder die durchgeführte Operation ist. Gehen Sie davon aus, dass Protokolldateien nicht geheim sind und Sie nicht in Versuchung kommen werden, sensible Informationen darin zu platzieren.

Versenken Sie Ihre Web-Apps nicht

Hätten Sie wirklich Informationen durchsickern lassen können, während Sie mit einem Freund sprachen, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Das ist die Lektion des Sprichworts "Lose Lippen versenken Schiffe".

Ebenso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung der Außenwelt preiszugeben. Es gibt keinen Grund, ganze Kreditkartennummern oder Passwörter einzusehen. Es gibt keinen Grund, PII-Daten in Protokolldateien zu haben. Tun Sie es also nicht. Schauen Sie sich unsere Lernressourcen an, um mehr über die Offenlegung von Informationen zu erfahren.

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

Glauben Sie, dass Sie der Informationsaussetzung jetzt Einhalt gebieten können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]

Ressource anzeigen
Ressource anzeigen

Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher werden, in die Anwendung einzudringen. jIn diesem Beitrag erfahren Sie, was die Preisgabe von Informationen ist, warum sie gefährlich ist und wie Sie sie verhindern können.

Interessiert an mehr?

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchen
Weitergeben:
Autor
Jaap Karan Singh
Veröffentlicht am 02. Mai 2019

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Weitergeben:

"Lose Lippen versenken Schiffe" war eine Redewendung, die in den Vereinigten Staaten während des Zweiten Weltkriegs populär wurde. In Großbritannien hörte man "Careless talk costs lives". Die Hauptaussage des Sprichworts war, dass unvorsichtiges Sprechen über sensible Informationen von Spionen belauscht werden und zu ernsten Konsequenzen führen konnte.

Das gleiche Prinzip gilt für die Erstellung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher sein, in sie einzubrechen.

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

Verstehen der Informationsexposition

Informationsexposition bezieht sich auf Webanwendungen, die interne Informationen für Personen offenlegen, die sie nicht sehen sollten. Es kann sich auch auf die Offenlegung sensibler Kundeninformationen über Protokolldateien oder die Benutzeroberfläche beziehen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Benutzer anzugreifen.

Oft ist der erste Schritt für einen Angreifer der Versuch, einen Fehler innerhalb Ihrer Anwendung zu erzeugen. Schlechte Fehlerbehandlung und Webanwendungskonfiguration führt zur Offenlegung von Informationen durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler innerhalb Ihrer Anwendung erzeugt? Wenn eine technische Fehlermeldung erscheint, die technische Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können beinhalten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers Sie einsetzen.

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

Kurz gesagt: Informationsexposition tritt auf, wenn Informationen, die Ihre Benutzer nur auf einer Need-to-know-Basis kennen sollten, zu leicht zugänglich gemacht werden.

Verstehen Sie, warum die Exposition gegenüber Informationen gefährlich ist

Was kann ein Angreifer mit den von der Anwendung offengelegten Informationen tun? Wenn die Informationen sensibler Natur sind, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies könnte zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen

Wenn ein Angreifer Fehlermeldungen verwendet, um Informationen über eine Anwendung zu erhalten, könnten diese Informationen in einem zukünftigen Angriff verwendet werden. Tatsächlich gibt es im OWASP Testing Guide einen ganzen Abschnitt über das Sammeln von Informationen.

Der OWASP Testing Guide ermutigt die Verwendung von Suchmaschinen, um Informationen über Ihre Website herauszufinden, die Sie vielleicht nicht beabsichtigen. Sind zum Beispiel Ihre administrativen Seiten für Suchmaschinen zugänglich? Verwenden Sie die Datei robots.txt, um Suchmaschinen mitzuteilen, dass sie bestimmte Seiten nicht indizieren sollen. Gleichzeitig kann die robots.txt-Datei aber auch Informationen preisgeben. Sensible URLs können sich zuweilen in der robots.txt-Datei befinden. Die Angreifer ziehen die Datei herunter und beginnen, einen Teil der Verzeichnisstruktur der Website zu erfahren.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP-Header, Website-Banner und sogar Kommentare in HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern preisgeben. Angreifer können diese Informationen nutzen, um Exploits zu finden, die gegen diese spezifischen Versionen eingesetzt werden können. Vergewissern Sie sich, dass Sie all die verschiedenen Stellen kennen, an denen Angreifer Ihre Informationen finden könnten, und wie Sie sie angemessen verbergen können.

Beseitigen Sie die Informationsaussetzung

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

Wenn Sie für die Anwendung notwendige Dateien haben, die sensible Informationen enthalten, stellen Sie sicher, dass eine angemessene Zugriffskontrolle gewährleistet, dass nur die Anwendung selbst diese lesen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Root-Verzeichnisses. Dies verhindert, dass Angreifer mit dem Browser über einen Directory-Traversal-Angriff zu der Datei navigieren können.

Protokolle können zum Sammeln von Informationen verwendet werden, wenn sie nicht korrekt konfiguriert sind. Wenn ein Fehler auftritt, protokollieren Sie keine sensiblen Informationen wie Passwörter, Sitzungs-Tokens oder persönlich identifizierbare Informationen (PII). Wenn ein Angreifer Zugriff auf Protokolldateien erhalten könnte, würde er eine Fundgrube an sensiblen Informationen finden, die er stehlen könnte. Protokollieren Sie nicht mehr als nötig, was in der Regel eine Kontokennung, eine detaillierte Fehlermeldung und vielleicht die Methode, in der der Fehler aufgetreten ist, oder die durchgeführte Operation ist. Gehen Sie davon aus, dass Protokolldateien nicht geheim sind und Sie nicht in Versuchung kommen werden, sensible Informationen darin zu platzieren.

Versenken Sie Ihre Web-Apps nicht

Hätten Sie wirklich Informationen durchsickern lassen können, während Sie mit einem Freund sprachen, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Das ist die Lektion des Sprichworts "Lose Lippen versenken Schiffe".

Ebenso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung der Außenwelt preiszugeben. Es gibt keinen Grund, ganze Kreditkartennummern oder Passwörter einzusehen. Es gibt keinen Grund, PII-Daten in Protokolldateien zu haben. Tun Sie es also nicht. Schauen Sie sich unsere Lernressourcen an, um mehr über die Offenlegung von Informationen zu erfahren.

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

Glauben Sie, dass Sie der Informationsaussetzung jetzt Einhalt gebieten können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]

Ressource anzeigen
Ressource anzeigen

Füllen Sie das folgende Formular aus, um den Bericht herunterzuladen

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.

"Lose Lippen versenken Schiffe" war eine Redewendung, die in den Vereinigten Staaten während des Zweiten Weltkriegs populär wurde. In Großbritannien hörte man "Careless talk costs lives". Die Hauptaussage des Sprichworts war, dass unvorsichtiges Sprechen über sensible Informationen von Spionen belauscht werden und zu ernsten Konsequenzen führen konnte.

Das gleiche Prinzip gilt für die Erstellung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher sein, in sie einzubrechen.

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

Verstehen der Informationsexposition

Informationsexposition bezieht sich auf Webanwendungen, die interne Informationen für Personen offenlegen, die sie nicht sehen sollten. Es kann sich auch auf die Offenlegung sensibler Kundeninformationen über Protokolldateien oder die Benutzeroberfläche beziehen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Benutzer anzugreifen.

Oft ist der erste Schritt für einen Angreifer der Versuch, einen Fehler innerhalb Ihrer Anwendung zu erzeugen. Schlechte Fehlerbehandlung und Webanwendungskonfiguration führt zur Offenlegung von Informationen durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler innerhalb Ihrer Anwendung erzeugt? Wenn eine technische Fehlermeldung erscheint, die technische Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können beinhalten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers Sie einsetzen.

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

Kurz gesagt: Informationsexposition tritt auf, wenn Informationen, die Ihre Benutzer nur auf einer Need-to-know-Basis kennen sollten, zu leicht zugänglich gemacht werden.

Verstehen Sie, warum die Exposition gegenüber Informationen gefährlich ist

Was kann ein Angreifer mit den von der Anwendung offengelegten Informationen tun? Wenn die Informationen sensibler Natur sind, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies könnte zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen

Wenn ein Angreifer Fehlermeldungen verwendet, um Informationen über eine Anwendung zu erhalten, könnten diese Informationen in einem zukünftigen Angriff verwendet werden. Tatsächlich gibt es im OWASP Testing Guide einen ganzen Abschnitt über das Sammeln von Informationen.

Der OWASP Testing Guide ermutigt die Verwendung von Suchmaschinen, um Informationen über Ihre Website herauszufinden, die Sie vielleicht nicht beabsichtigen. Sind zum Beispiel Ihre administrativen Seiten für Suchmaschinen zugänglich? Verwenden Sie die Datei robots.txt, um Suchmaschinen mitzuteilen, dass sie bestimmte Seiten nicht indizieren sollen. Gleichzeitig kann die robots.txt-Datei aber auch Informationen preisgeben. Sensible URLs können sich zuweilen in der robots.txt-Datei befinden. Die Angreifer ziehen die Datei herunter und beginnen, einen Teil der Verzeichnisstruktur der Website zu erfahren.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP-Header, Website-Banner und sogar Kommentare in HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern preisgeben. Angreifer können diese Informationen nutzen, um Exploits zu finden, die gegen diese spezifischen Versionen eingesetzt werden können. Vergewissern Sie sich, dass Sie all die verschiedenen Stellen kennen, an denen Angreifer Ihre Informationen finden könnten, und wie Sie sie angemessen verbergen können.

Beseitigen Sie die Informationsaussetzung

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

Wenn Sie für die Anwendung notwendige Dateien haben, die sensible Informationen enthalten, stellen Sie sicher, dass eine angemessene Zugriffskontrolle gewährleistet, dass nur die Anwendung selbst diese lesen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Root-Verzeichnisses. Dies verhindert, dass Angreifer mit dem Browser über einen Directory-Traversal-Angriff zu der Datei navigieren können.

Protokolle können zum Sammeln von Informationen verwendet werden, wenn sie nicht korrekt konfiguriert sind. Wenn ein Fehler auftritt, protokollieren Sie keine sensiblen Informationen wie Passwörter, Sitzungs-Tokens oder persönlich identifizierbare Informationen (PII). Wenn ein Angreifer Zugriff auf Protokolldateien erhalten könnte, würde er eine Fundgrube an sensiblen Informationen finden, die er stehlen könnte. Protokollieren Sie nicht mehr als nötig, was in der Regel eine Kontokennung, eine detaillierte Fehlermeldung und vielleicht die Methode, in der der Fehler aufgetreten ist, oder die durchgeführte Operation ist. Gehen Sie davon aus, dass Protokolldateien nicht geheim sind und Sie nicht in Versuchung kommen werden, sensible Informationen darin zu platzieren.

Versenken Sie Ihre Web-Apps nicht

Hätten Sie wirklich Informationen durchsickern lassen können, während Sie mit einem Freund sprachen, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Das ist die Lektion des Sprichworts "Lose Lippen versenken Schiffe".

Ebenso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung der Außenwelt preiszugeben. Es gibt keinen Grund, ganze Kreditkartennummern oder Passwörter einzusehen. Es gibt keinen Grund, PII-Daten in Protokolldateien zu haben. Tun Sie es also nicht. Schauen Sie sich unsere Lernressourcen an, um mehr über die Offenlegung von Informationen zu erfahren.

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

Glauben Sie, dass Sie der Informationsaussetzung jetzt Einhalt gebieten können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]

Starten

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Bericht ansehenDemo buchen
Ressource anzeigen
Weitergeben:
Interessiert an mehr?

Weitergeben:
Autor
Jaap Karan Singh
Veröffentlicht am 02. Mai 2019

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Weitergeben:

"Lose Lippen versenken Schiffe" war eine Redewendung, die in den Vereinigten Staaten während des Zweiten Weltkriegs populär wurde. In Großbritannien hörte man "Careless talk costs lives". Die Hauptaussage des Sprichworts war, dass unvorsichtiges Sprechen über sensible Informationen von Spionen belauscht werden und zu ernsten Konsequenzen führen konnte.

Das gleiche Prinzip gilt für die Erstellung von Webanwendungen. Wenn Ihre Webanwendung zu viele Informationen preisgibt, kann es für Angreifer einfacher sein, in sie einzubrechen.

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

Verstehen der Informationsexposition

Informationsexposition bezieht sich auf Webanwendungen, die interne Informationen für Personen offenlegen, die sie nicht sehen sollten. Es kann sich auch auf die Offenlegung sensibler Kundeninformationen über Protokolldateien oder die Benutzeroberfläche beziehen. In jedem Fall können Angreifer die gefundenen Informationen nutzen, um Ihre Systeme oder Ihre Benutzer anzugreifen.

Oft ist der erste Schritt für einen Angreifer der Versuch, einen Fehler innerhalb Ihrer Anwendung zu erzeugen. Schlechte Fehlerbehandlung und Webanwendungskonfiguration führt zur Offenlegung von Informationen durch Fehlermeldungen. Was passiert, wenn der Angreifer einen Fehler innerhalb Ihrer Anwendung erzeugt? Wenn eine technische Fehlermeldung erscheint, die technische Details wie einen Stack-Trace enthält, haben Sie zu viele Informationen preisgegeben. Diese Details können beinhalten, welche Datenbank Sie verwenden oder welche Version des Anwendungsservers Sie einsetzen.

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

Kurz gesagt: Informationsexposition tritt auf, wenn Informationen, die Ihre Benutzer nur auf einer Need-to-know-Basis kennen sollten, zu leicht zugänglich gemacht werden.

Verstehen Sie, warum die Exposition gegenüber Informationen gefährlich ist

Was kann ein Angreifer mit den von der Anwendung offengelegten Informationen tun? Wenn die Informationen sensibler Natur sind, könnte ein Angreifer Identitäten oder Benutzeranmeldedaten stehlen. Dies könnte zu finanziellen Schäden, Datenschutzverletzungen und behördlichen Bußgeldern führen

Wenn ein Angreifer Fehlermeldungen verwendet, um Informationen über eine Anwendung zu erhalten, könnten diese Informationen in einem zukünftigen Angriff verwendet werden. Tatsächlich gibt es im OWASP Testing Guide einen ganzen Abschnitt über das Sammeln von Informationen.

Der OWASP Testing Guide ermutigt die Verwendung von Suchmaschinen, um Informationen über Ihre Website herauszufinden, die Sie vielleicht nicht beabsichtigen. Sind zum Beispiel Ihre administrativen Seiten für Suchmaschinen zugänglich? Verwenden Sie die Datei robots.txt, um Suchmaschinen mitzuteilen, dass sie bestimmte Seiten nicht indizieren sollen. Gleichzeitig kann die robots.txt-Datei aber auch Informationen preisgeben. Sensible URLs können sich zuweilen in der robots.txt-Datei befinden. Die Angreifer ziehen die Datei herunter und beginnen, einen Teil der Verzeichnisstruktur der Website zu erfahren.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP-Header, Website-Banner und sogar Kommentare in HTML- und JavaScript-Code können Informationen enthalten, die Angreifer nicht sehen sollten. HTTP-Header können Anwendungsserver und Versionsnummern preisgeben. Angreifer können diese Informationen nutzen, um Exploits zu finden, die gegen diese spezifischen Versionen eingesetzt werden können. Vergewissern Sie sich, dass Sie all die verschiedenen Stellen kennen, an denen Angreifer Ihre Informationen finden könnten, und wie Sie sie angemessen verbergen können.

Beseitigen Sie die Informationsaussetzung

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

Wenn Sie für die Anwendung notwendige Dateien haben, die sensible Informationen enthalten, stellen Sie sicher, dass eine angemessene Zugriffskontrolle gewährleistet, dass nur die Anwendung selbst diese lesen kann. Deaktivieren Sie die Verzeichnisauflistung auf dem Server und verschieben Sie diese Dateien außerhalb des Web-Root-Verzeichnisses. Dies verhindert, dass Angreifer mit dem Browser über einen Directory-Traversal-Angriff zu der Datei navigieren können.

Protokolle können zum Sammeln von Informationen verwendet werden, wenn sie nicht korrekt konfiguriert sind. Wenn ein Fehler auftritt, protokollieren Sie keine sensiblen Informationen wie Passwörter, Sitzungs-Tokens oder persönlich identifizierbare Informationen (PII). Wenn ein Angreifer Zugriff auf Protokolldateien erhalten könnte, würde er eine Fundgrube an sensiblen Informationen finden, die er stehlen könnte. Protokollieren Sie nicht mehr als nötig, was in der Regel eine Kontokennung, eine detaillierte Fehlermeldung und vielleicht die Methode, in der der Fehler aufgetreten ist, oder die durchgeführte Operation ist. Gehen Sie davon aus, dass Protokolldateien nicht geheim sind und Sie nicht in Versuchung kommen werden, sensible Informationen darin zu platzieren.

Versenken Sie Ihre Web-Apps nicht

Hätten Sie wirklich Informationen durchsickern lassen können, während Sie mit einem Freund sprachen, die direkt zum Verlust eines Schlachtschiffs im Zweiten Weltkrieg führten? Vielleicht nicht. Aber warum das Risiko eingehen? Das ist die Lektion des Sprichworts "Lose Lippen versenken Schiffe".

Ebenso gibt es keinen Grund, die internen Abläufe Ihrer Webanwendung der Außenwelt preiszugeben. Es gibt keinen Grund, ganze Kreditkartennummern oder Passwörter einzusehen. Es gibt keinen Grund, PII-Daten in Protokolldateien zu haben. Tun Sie es also nicht. Schauen Sie sich unsere Lernressourcen an, um mehr über die Offenlegung von Informationen zu erfahren.

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

Glauben Sie, dass Sie der Informationsaussetzung jetzt Einhalt gebieten können? Stellen Sie sich der Herausforderung, Krieger: [Hier starten]

Inhaltsübersicht

PDF herunterladen
Ressource anzeigen
Interessiert an mehr?

Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.

Demo buchenHerunterladen
Weitergeben:
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge
Ressourcendrehscheibe

Ressourcen für den Einstieg

Mehr Beiträge