
コーダーがセキュリティを征服する:共有して学ぶシリーズ-情報公開
"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は、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

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.
デモを予約Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。


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

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

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デモを予約Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
"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は、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。

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.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.




%20(1).avif)
.avif)
