SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

コーダーがセキュリティを征服する:共有して学ぶシリーズ-情報公開

ヤープ・キャラン・シン
Veröffentlicht am 02. Mai 2019
Zuletzt aktualisiert am 10. März 2026

"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]

リソースを表示
リソースを表示

ウェブアプリがあまりにも多くの情報を公開すると、攻撃者が侵入しやすくなる可能性があります。この記事では、情報漏えいとは何か、なぜ危険なのか、そしてそれを防ぐ方法について説明します。

もっと興味がありますか?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

mehr erfahren

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

デモを予約
シェア:
LinkedIn-MarkenSozialx Logo
Autor
ヤープ・キャラン・シン
Veröffentlicht am 02. Mai 2019

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

シェア:
LinkedIn-MarkenSozialx Logo

"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]

リソースを表示
リソースを表示

Um den Bericht herunterzuladen, füllen Sie bitte das folgende Formular aus.

Wir bitten um Ihre Erlaubnis, Ihnen Informationen zu unseren Produkten und/oder zu Themen rund um sicheres Programmieren zuzusenden. Wir behandeln Ihre personenbezogenen Daten stets mit größter Sorgfalt und verkaufen sie niemals zu Marketingzwecken an andere Unternehmen weiter.

送信
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte das „Analytics“-Cookie. Nach Abschluss der Einstellungen können Sie es wieder deaktivieren.

"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]

Online-Seminar ansehen
Beginnen wir
mehr erfahren

Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

Bericht anzeigenデモを予約
PDF herunterladen
リソースを表示
シェア:
LinkedIn-MarkenSozialx Logo
もっと興味がありますか?

シェア:
LinkedIn-MarkenSozialx Logo
Autor
ヤープ・キャラン・シン
Veröffentlicht am 02. Mai 2019

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

シェア:
LinkedIn-MarkenSozialx Logo

"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]

目次

PDF herunterladen
リソースを表示
もっと興味がありますか?

Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

mehr erfahren

Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.

デモを予約[ダウンロード]
シェア:
LinkedIn-MarkenSozialx Logo
リソースハブ

Ressourcen für den Einstieg

Weitere Beiträge
リソースハブ

Ressourcen für den Einstieg

Weitere Beiträge