
Coders Conquer Security: Share & Learn-Serie — Ungenügender Schutz der Transportebene
Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig gesichert haben, kann die Kommunikation dennoch anfällig für Schnüffeln sein, wenn Sie über einen unzureichenden Schutz auf der Transportebene verfügen. In der physischen Welt besteht der Grund dafür, dass harte Währungen mit gepanzerten Autos bewegt werden, darin, sie während des Transports zu schützen. Es spielt wirklich keine Rolle, wie sicher ein Geschäft oder eine Bank ist, wenn das Geld, das damit generiert wird, für eine Fahrt durch die Stadt in einen Golfwagen geladen wird.
Das Gleiche gilt für Transportschichten im Cyberbereich. Selbst wenn eine Anwendung sicher ist, besteht immer noch eine kritische Sicherheitslücke, wenn die in sie eingehenden Informationen ungeschützt gesendet werden. Und bei einigen Apps gibt es eine zweite Sicherheitslücke, wenn sie zusätzlich Informationen an andere Server oder eine Datenbank senden. Diese Informationen könnten Insidern zugänglich gemacht werden, die nichts damit zu tun haben, diese Transaktionen auszuspionieren.
Um Benutzer und Daten vollständig zu schützen, muss die Transportebene geschützt werden. Nur so können Sie eine gesamte Transaktion von Anfang bis Ende vollständig sichern.
In dieser Episode werden wir lernen:
- Wie Hacker den unzureichenden Schutz der Transportschicht ausnutzen können
- Warum ist es so gefährlich, die Transportschicht nicht zu schützen
- Was kann getan werden, um den Transport aller Daten, die in und durch eine Anwendung oder einen Server übertragen werden, zu sichern?
Wie nutzen Angreifer einen unzureichenden Schutz auf der Transportebene aus?
Ein unzureichender Schutz auf der Transportebene kann Angriffe an zwei Stellen in Ihrem Datenstrom ermöglichen. Die am häufigsten ausgenutzte Stelle befindet sich zwischen einem Benutzer und dem Anwendungsserver. Wenn Informationen unverschlüsselt oder mit schwacher Verschlüsselung gesendet werden, können Hacker diese Informationen überwachen, stehlen und möglicherweise ändern. Dies könnte es Hackern ermöglichen, die Kreditkarte eines Benutzers, seine Anmeldeinformationen oder alles andere, was an den Anwendungsserver gesendet wurde, zu stehlen. Selbst wenn der Server selbst sicher ist, kann ein Hacker, der den unsicheren Kanal zwischen ihm und den Benutzern überwacht, nahezu uneingeschränkten Zugriff auf viele Informationen erhalten.
Der zweite Punkt, der oft ungeschützt bleibt, ist die Transportschicht zwischen einer Anwendung und dem Rest des Netzwerks. Beispielsweise kann ein Anwendungsserver Online-Bestellungen verarbeiten und sie dann an ein Fulfillment-System weiterleiten, oder Daten könnten einfach zur Speicherung in eine Datenbank ausgelagert werden. Wenn diese internen Kanäle ungeschützt sind, können interne Benutzer diese Informationen möglicherweise sehen.
Es ist zwar schön zu glauben, dass alle internen Benutzer gute Menschen sind, aber Tatsache ist, dass Insider-Bedrohungen in vielen Branchen zunehmen. Insider wurden dabei erwischt, wie sie im Gegenzug für das Sammeln vertraulicher Informationen für Angreifer oder Konkurrenten Bestechungsgelder annahmen. Und der Zugang zu so etwas wie Tausenden von gültigen Kreditkarten könnte für manche Menschen einfach zu verlockend sein, um sie zu ignorieren.
Was die Angriffstechniken angeht, ist es nicht sehr schwierig, ungeschützte Kommunikation abzufangen. Selbst Hacker auf niedriger Ebene wissen, wie man Man-in-the-Middle-Angriffe gegen unverschlüsselte Datenströme durchführt. Wenn sie es nicht tun, gibt es Videos im Internet, mit denen sie in weniger als einer halben Stunde geschult werden können.
Warum sind Sicherheitslücken beim unzureichenden Schutz der Transportebene so gefährlich?
Ein unzureichender oder nicht vorhandener Schutz auf den Transportebenen ist gefährlich, da es Hackern so extrem leicht fällt, vertrauliche Informationen zu sammeln. Sie müssen nicht in Ihren App-Server einbrechen oder Ihr Netzwerk hacken. Sie richten einfach einen Man-in-the-Middle-Angriff ein und lesen alles, was von Benutzern an einen Server gesendet wird. Dazu können Benutzernamen und Passwörter gehören, mit denen die Sicherheit in Zukunft mithilfe gültiger Anmeldeinformationen umgangen werden kann. Je nach Anwendung können dazu auch Kreditkarteninformationen oder andere persönliche Daten von Benutzern gehören.
Und es ist wichtig zu beachten, dass all dieses Schnüffeln außerhalb Ihres Netzwerks stattfindet. Wenn Sie unsichere Transportkanäle verwenden, können Sie nicht feststellen, ob jemand diese Informationen erfasst. Normalerweise ist das erste Anzeichen, wenn viele Benutzer anfangen, kompromittierte Konten oder Kreditkartenkäufe zu melden, und der gemeinsame Faktor ist, dass Ihre Bewerbung "kein guter Ort dafür ist. Hacker können auch Informationen ändern, sobald sie sie haben. So können sie beispielsweise die Lieferadresse ändern oder sogar bösartige Skripte in die Serverantwort einfügen, bevor sie sie an die Benutzer weitergeben.
Im Backend werden Daten durch das Versäumnis, die Transportebene zu sichern, Insidern zugänglich gemacht. Es ist wahrscheinlich viel weniger wahrscheinlich, dass ein Insider die Transportebene ausspioniert als Hacker von außen, die dasselbe tun. Aber es ist auch gefährlicher, wenn es passiert, da die Insider-Bedrohung nicht nur die Benutzerdaten, sondern auch alle vom App-Server hinzugefügten proprietären Informationen sehen kann, bevor sie diese Pakete versendet.
Beseitigung unzureichender Sicherheitslücken beim Schutz der Transportebene
So gefährlich ein unzureichender Schutz der Transportschicht auch sein mag, es ist auch nicht unglaublich schwierig, alle Transportkanäle ordnungsgemäß abzusichern. Es beginnt mit der Backend-Infrastruktur. Dies sollte ausschließlich HTTPS sein. Achten Sie darauf, HTTPS und HTTP auf einer Website nicht zu vermischen. Schließlich sollten Sie ein gültiges SSL-Zertifikat mit einer Mindestschlüsselgröße von 2048 Bit beibehalten und gleichzeitig alle Benutzer dazu zwingen, über gesicherte Browser mit HTTP Strict Transport Security (HSTS) zu interagieren.
Sobald die Infrastruktur eingerichtet ist, sollten Entwickler ein starkes Protokoll verwenden, um die Transportschicht zu schützen. Idealerweise sollte TLS 1.2 verwendet werden, obwohl TLS 1.1 und 1.0 auch akzeptabel sind, wenn dies unbedingt erforderlich ist. Sobald dies geschehen ist, sollten schwache Protokolle wie SSLv2 vollständig deaktiviert und niemals unterstützt werden.
Es sollte auch darauf geachtet werden, dass kryptografische Chiffren im Backend ausreichend leistungsfähig sind. Idealerweise sollte die Mindestgröße des Sitzungsschlüssels 128 Bit betragen. Wie bei Protokollen sollte die Unterstützung für schwache kryptografische Algorithmen wie DES und RC4-40 deaktiviert werden. Und schließlich sollten Sie eine Anwendung erst dann als wirklich sicher betrachten, wenn sowohl der Server selbst als auch alle Datenpfade, die in ihn hinein und aus ihm heraus führen, ausreichend geschützt sind.
Weitere Informationen zu Sicherheitslücken beim unzureichenden Schutz der Transportebene
Für weitere Informationen können Sie sich die OWASP ansehen Leitfaden zum Schutz Transportschichten. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.


Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig gesichert haben, kann die Kommunikation dennoch anfällig für Schnüffeln sein, wenn Sie über einen unzureichenden Schutz auf der Transportebene verfügen.
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationJaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.


Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig gesichert haben, kann die Kommunikation dennoch anfällig für Schnüffeln sein, wenn Sie über einen unzureichenden Schutz auf der Transportebene verfügen. In der physischen Welt besteht der Grund dafür, dass harte Währungen mit gepanzerten Autos bewegt werden, darin, sie während des Transports zu schützen. Es spielt wirklich keine Rolle, wie sicher ein Geschäft oder eine Bank ist, wenn das Geld, das damit generiert wird, für eine Fahrt durch die Stadt in einen Golfwagen geladen wird.
Das Gleiche gilt für Transportschichten im Cyberbereich. Selbst wenn eine Anwendung sicher ist, besteht immer noch eine kritische Sicherheitslücke, wenn die in sie eingehenden Informationen ungeschützt gesendet werden. Und bei einigen Apps gibt es eine zweite Sicherheitslücke, wenn sie zusätzlich Informationen an andere Server oder eine Datenbank senden. Diese Informationen könnten Insidern zugänglich gemacht werden, die nichts damit zu tun haben, diese Transaktionen auszuspionieren.
Um Benutzer und Daten vollständig zu schützen, muss die Transportebene geschützt werden. Nur so können Sie eine gesamte Transaktion von Anfang bis Ende vollständig sichern.
In dieser Episode werden wir lernen:
- Wie Hacker den unzureichenden Schutz der Transportschicht ausnutzen können
- Warum ist es so gefährlich, die Transportschicht nicht zu schützen
- Was kann getan werden, um den Transport aller Daten, die in und durch eine Anwendung oder einen Server übertragen werden, zu sichern?
Wie nutzen Angreifer einen unzureichenden Schutz auf der Transportebene aus?
Ein unzureichender Schutz auf der Transportebene kann Angriffe an zwei Stellen in Ihrem Datenstrom ermöglichen. Die am häufigsten ausgenutzte Stelle befindet sich zwischen einem Benutzer und dem Anwendungsserver. Wenn Informationen unverschlüsselt oder mit schwacher Verschlüsselung gesendet werden, können Hacker diese Informationen überwachen, stehlen und möglicherweise ändern. Dies könnte es Hackern ermöglichen, die Kreditkarte eines Benutzers, seine Anmeldeinformationen oder alles andere, was an den Anwendungsserver gesendet wurde, zu stehlen. Selbst wenn der Server selbst sicher ist, kann ein Hacker, der den unsicheren Kanal zwischen ihm und den Benutzern überwacht, nahezu uneingeschränkten Zugriff auf viele Informationen erhalten.
Der zweite Punkt, der oft ungeschützt bleibt, ist die Transportschicht zwischen einer Anwendung und dem Rest des Netzwerks. Beispielsweise kann ein Anwendungsserver Online-Bestellungen verarbeiten und sie dann an ein Fulfillment-System weiterleiten, oder Daten könnten einfach zur Speicherung in eine Datenbank ausgelagert werden. Wenn diese internen Kanäle ungeschützt sind, können interne Benutzer diese Informationen möglicherweise sehen.
Es ist zwar schön zu glauben, dass alle internen Benutzer gute Menschen sind, aber Tatsache ist, dass Insider-Bedrohungen in vielen Branchen zunehmen. Insider wurden dabei erwischt, wie sie im Gegenzug für das Sammeln vertraulicher Informationen für Angreifer oder Konkurrenten Bestechungsgelder annahmen. Und der Zugang zu so etwas wie Tausenden von gültigen Kreditkarten könnte für manche Menschen einfach zu verlockend sein, um sie zu ignorieren.
Was die Angriffstechniken angeht, ist es nicht sehr schwierig, ungeschützte Kommunikation abzufangen. Selbst Hacker auf niedriger Ebene wissen, wie man Man-in-the-Middle-Angriffe gegen unverschlüsselte Datenströme durchführt. Wenn sie es nicht tun, gibt es Videos im Internet, mit denen sie in weniger als einer halben Stunde geschult werden können.
Warum sind Sicherheitslücken beim unzureichenden Schutz der Transportebene so gefährlich?
Ein unzureichender oder nicht vorhandener Schutz auf den Transportebenen ist gefährlich, da es Hackern so extrem leicht fällt, vertrauliche Informationen zu sammeln. Sie müssen nicht in Ihren App-Server einbrechen oder Ihr Netzwerk hacken. Sie richten einfach einen Man-in-the-Middle-Angriff ein und lesen alles, was von Benutzern an einen Server gesendet wird. Dazu können Benutzernamen und Passwörter gehören, mit denen die Sicherheit in Zukunft mithilfe gültiger Anmeldeinformationen umgangen werden kann. Je nach Anwendung können dazu auch Kreditkarteninformationen oder andere persönliche Daten von Benutzern gehören.
Und es ist wichtig zu beachten, dass all dieses Schnüffeln außerhalb Ihres Netzwerks stattfindet. Wenn Sie unsichere Transportkanäle verwenden, können Sie nicht feststellen, ob jemand diese Informationen erfasst. Normalerweise ist das erste Anzeichen, wenn viele Benutzer anfangen, kompromittierte Konten oder Kreditkartenkäufe zu melden, und der gemeinsame Faktor ist, dass Ihre Bewerbung "kein guter Ort dafür ist. Hacker können auch Informationen ändern, sobald sie sie haben. So können sie beispielsweise die Lieferadresse ändern oder sogar bösartige Skripte in die Serverantwort einfügen, bevor sie sie an die Benutzer weitergeben.
Im Backend werden Daten durch das Versäumnis, die Transportebene zu sichern, Insidern zugänglich gemacht. Es ist wahrscheinlich viel weniger wahrscheinlich, dass ein Insider die Transportebene ausspioniert als Hacker von außen, die dasselbe tun. Aber es ist auch gefährlicher, wenn es passiert, da die Insider-Bedrohung nicht nur die Benutzerdaten, sondern auch alle vom App-Server hinzugefügten proprietären Informationen sehen kann, bevor sie diese Pakete versendet.
Beseitigung unzureichender Sicherheitslücken beim Schutz der Transportebene
So gefährlich ein unzureichender Schutz der Transportschicht auch sein mag, es ist auch nicht unglaublich schwierig, alle Transportkanäle ordnungsgemäß abzusichern. Es beginnt mit der Backend-Infrastruktur. Dies sollte ausschließlich HTTPS sein. Achten Sie darauf, HTTPS und HTTP auf einer Website nicht zu vermischen. Schließlich sollten Sie ein gültiges SSL-Zertifikat mit einer Mindestschlüsselgröße von 2048 Bit beibehalten und gleichzeitig alle Benutzer dazu zwingen, über gesicherte Browser mit HTTP Strict Transport Security (HSTS) zu interagieren.
Sobald die Infrastruktur eingerichtet ist, sollten Entwickler ein starkes Protokoll verwenden, um die Transportschicht zu schützen. Idealerweise sollte TLS 1.2 verwendet werden, obwohl TLS 1.1 und 1.0 auch akzeptabel sind, wenn dies unbedingt erforderlich ist. Sobald dies geschehen ist, sollten schwache Protokolle wie SSLv2 vollständig deaktiviert und niemals unterstützt werden.
Es sollte auch darauf geachtet werden, dass kryptografische Chiffren im Backend ausreichend leistungsfähig sind. Idealerweise sollte die Mindestgröße des Sitzungsschlüssels 128 Bit betragen. Wie bei Protokollen sollte die Unterstützung für schwache kryptografische Algorithmen wie DES und RC4-40 deaktiviert werden. Und schließlich sollten Sie eine Anwendung erst dann als wirklich sicher betrachten, wenn sowohl der Server selbst als auch alle Datenpfade, die in ihn hinein und aus ihm heraus führen, ausreichend geschützt sind.
Weitere Informationen zu Sicherheitslücken beim unzureichenden Schutz der Transportebene
Für weitere Informationen können Sie sich die OWASP ansehen Leitfaden zum Schutz Transportschichten. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.

Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig gesichert haben, kann die Kommunikation dennoch anfällig für Schnüffeln sein, wenn Sie über einen unzureichenden Schutz auf der Transportebene verfügen. In der physischen Welt besteht der Grund dafür, dass harte Währungen mit gepanzerten Autos bewegt werden, darin, sie während des Transports zu schützen. Es spielt wirklich keine Rolle, wie sicher ein Geschäft oder eine Bank ist, wenn das Geld, das damit generiert wird, für eine Fahrt durch die Stadt in einen Golfwagen geladen wird.
Das Gleiche gilt für Transportschichten im Cyberbereich. Selbst wenn eine Anwendung sicher ist, besteht immer noch eine kritische Sicherheitslücke, wenn die in sie eingehenden Informationen ungeschützt gesendet werden. Und bei einigen Apps gibt es eine zweite Sicherheitslücke, wenn sie zusätzlich Informationen an andere Server oder eine Datenbank senden. Diese Informationen könnten Insidern zugänglich gemacht werden, die nichts damit zu tun haben, diese Transaktionen auszuspionieren.
Um Benutzer und Daten vollständig zu schützen, muss die Transportebene geschützt werden. Nur so können Sie eine gesamte Transaktion von Anfang bis Ende vollständig sichern.
In dieser Episode werden wir lernen:
- Wie Hacker den unzureichenden Schutz der Transportschicht ausnutzen können
- Warum ist es so gefährlich, die Transportschicht nicht zu schützen
- Was kann getan werden, um den Transport aller Daten, die in und durch eine Anwendung oder einen Server übertragen werden, zu sichern?
Wie nutzen Angreifer einen unzureichenden Schutz auf der Transportebene aus?
Ein unzureichender Schutz auf der Transportebene kann Angriffe an zwei Stellen in Ihrem Datenstrom ermöglichen. Die am häufigsten ausgenutzte Stelle befindet sich zwischen einem Benutzer und dem Anwendungsserver. Wenn Informationen unverschlüsselt oder mit schwacher Verschlüsselung gesendet werden, können Hacker diese Informationen überwachen, stehlen und möglicherweise ändern. Dies könnte es Hackern ermöglichen, die Kreditkarte eines Benutzers, seine Anmeldeinformationen oder alles andere, was an den Anwendungsserver gesendet wurde, zu stehlen. Selbst wenn der Server selbst sicher ist, kann ein Hacker, der den unsicheren Kanal zwischen ihm und den Benutzern überwacht, nahezu uneingeschränkten Zugriff auf viele Informationen erhalten.
Der zweite Punkt, der oft ungeschützt bleibt, ist die Transportschicht zwischen einer Anwendung und dem Rest des Netzwerks. Beispielsweise kann ein Anwendungsserver Online-Bestellungen verarbeiten und sie dann an ein Fulfillment-System weiterleiten, oder Daten könnten einfach zur Speicherung in eine Datenbank ausgelagert werden. Wenn diese internen Kanäle ungeschützt sind, können interne Benutzer diese Informationen möglicherweise sehen.
Es ist zwar schön zu glauben, dass alle internen Benutzer gute Menschen sind, aber Tatsache ist, dass Insider-Bedrohungen in vielen Branchen zunehmen. Insider wurden dabei erwischt, wie sie im Gegenzug für das Sammeln vertraulicher Informationen für Angreifer oder Konkurrenten Bestechungsgelder annahmen. Und der Zugang zu so etwas wie Tausenden von gültigen Kreditkarten könnte für manche Menschen einfach zu verlockend sein, um sie zu ignorieren.
Was die Angriffstechniken angeht, ist es nicht sehr schwierig, ungeschützte Kommunikation abzufangen. Selbst Hacker auf niedriger Ebene wissen, wie man Man-in-the-Middle-Angriffe gegen unverschlüsselte Datenströme durchführt. Wenn sie es nicht tun, gibt es Videos im Internet, mit denen sie in weniger als einer halben Stunde geschult werden können.
Warum sind Sicherheitslücken beim unzureichenden Schutz der Transportebene so gefährlich?
Ein unzureichender oder nicht vorhandener Schutz auf den Transportebenen ist gefährlich, da es Hackern so extrem leicht fällt, vertrauliche Informationen zu sammeln. Sie müssen nicht in Ihren App-Server einbrechen oder Ihr Netzwerk hacken. Sie richten einfach einen Man-in-the-Middle-Angriff ein und lesen alles, was von Benutzern an einen Server gesendet wird. Dazu können Benutzernamen und Passwörter gehören, mit denen die Sicherheit in Zukunft mithilfe gültiger Anmeldeinformationen umgangen werden kann. Je nach Anwendung können dazu auch Kreditkarteninformationen oder andere persönliche Daten von Benutzern gehören.
Und es ist wichtig zu beachten, dass all dieses Schnüffeln außerhalb Ihres Netzwerks stattfindet. Wenn Sie unsichere Transportkanäle verwenden, können Sie nicht feststellen, ob jemand diese Informationen erfasst. Normalerweise ist das erste Anzeichen, wenn viele Benutzer anfangen, kompromittierte Konten oder Kreditkartenkäufe zu melden, und der gemeinsame Faktor ist, dass Ihre Bewerbung "kein guter Ort dafür ist. Hacker können auch Informationen ändern, sobald sie sie haben. So können sie beispielsweise die Lieferadresse ändern oder sogar bösartige Skripte in die Serverantwort einfügen, bevor sie sie an die Benutzer weitergeben.
Im Backend werden Daten durch das Versäumnis, die Transportebene zu sichern, Insidern zugänglich gemacht. Es ist wahrscheinlich viel weniger wahrscheinlich, dass ein Insider die Transportebene ausspioniert als Hacker von außen, die dasselbe tun. Aber es ist auch gefährlicher, wenn es passiert, da die Insider-Bedrohung nicht nur die Benutzerdaten, sondern auch alle vom App-Server hinzugefügten proprietären Informationen sehen kann, bevor sie diese Pakete versendet.
Beseitigung unzureichender Sicherheitslücken beim Schutz der Transportebene
So gefährlich ein unzureichender Schutz der Transportschicht auch sein mag, es ist auch nicht unglaublich schwierig, alle Transportkanäle ordnungsgemäß abzusichern. Es beginnt mit der Backend-Infrastruktur. Dies sollte ausschließlich HTTPS sein. Achten Sie darauf, HTTPS und HTTP auf einer Website nicht zu vermischen. Schließlich sollten Sie ein gültiges SSL-Zertifikat mit einer Mindestschlüsselgröße von 2048 Bit beibehalten und gleichzeitig alle Benutzer dazu zwingen, über gesicherte Browser mit HTTP Strict Transport Security (HSTS) zu interagieren.
Sobald die Infrastruktur eingerichtet ist, sollten Entwickler ein starkes Protokoll verwenden, um die Transportschicht zu schützen. Idealerweise sollte TLS 1.2 verwendet werden, obwohl TLS 1.1 und 1.0 auch akzeptabel sind, wenn dies unbedingt erforderlich ist. Sobald dies geschehen ist, sollten schwache Protokolle wie SSLv2 vollständig deaktiviert und niemals unterstützt werden.
Es sollte auch darauf geachtet werden, dass kryptografische Chiffren im Backend ausreichend leistungsfähig sind. Idealerweise sollte die Mindestgröße des Sitzungsschlüssels 128 Bit betragen. Wie bei Protokollen sollte die Unterstützung für schwache kryptografische Algorithmen wie DES und RC4-40 deaktiviert werden. Und schließlich sollten Sie eine Anwendung erst dann als wirklich sicher betrachten, wenn sowohl der Server selbst als auch alle Datenpfade, die in ihn hinein und aus ihm heraus führen, ausreichend geschützt sind.
Weitere Informationen zu Sicherheitslücken beim unzureichenden Schutz der Transportebene
Für weitere Informationen können Sie sich die OWASP ansehen Leitfaden zum Schutz Transportschichten. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstrationJaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Selbst wenn Sie einen Anwendungsserver und die von ihm verwendeten Backend-Systeme vollständig gesichert haben, kann die Kommunikation dennoch anfällig für Schnüffeln sein, wenn Sie über einen unzureichenden Schutz auf der Transportebene verfügen. In der physischen Welt besteht der Grund dafür, dass harte Währungen mit gepanzerten Autos bewegt werden, darin, sie während des Transports zu schützen. Es spielt wirklich keine Rolle, wie sicher ein Geschäft oder eine Bank ist, wenn das Geld, das damit generiert wird, für eine Fahrt durch die Stadt in einen Golfwagen geladen wird.
Das Gleiche gilt für Transportschichten im Cyberbereich. Selbst wenn eine Anwendung sicher ist, besteht immer noch eine kritische Sicherheitslücke, wenn die in sie eingehenden Informationen ungeschützt gesendet werden. Und bei einigen Apps gibt es eine zweite Sicherheitslücke, wenn sie zusätzlich Informationen an andere Server oder eine Datenbank senden. Diese Informationen könnten Insidern zugänglich gemacht werden, die nichts damit zu tun haben, diese Transaktionen auszuspionieren.
Um Benutzer und Daten vollständig zu schützen, muss die Transportebene geschützt werden. Nur so können Sie eine gesamte Transaktion von Anfang bis Ende vollständig sichern.
In dieser Episode werden wir lernen:
- Wie Hacker den unzureichenden Schutz der Transportschicht ausnutzen können
- Warum ist es so gefährlich, die Transportschicht nicht zu schützen
- Was kann getan werden, um den Transport aller Daten, die in und durch eine Anwendung oder einen Server übertragen werden, zu sichern?
Wie nutzen Angreifer einen unzureichenden Schutz auf der Transportebene aus?
Ein unzureichender Schutz auf der Transportebene kann Angriffe an zwei Stellen in Ihrem Datenstrom ermöglichen. Die am häufigsten ausgenutzte Stelle befindet sich zwischen einem Benutzer und dem Anwendungsserver. Wenn Informationen unverschlüsselt oder mit schwacher Verschlüsselung gesendet werden, können Hacker diese Informationen überwachen, stehlen und möglicherweise ändern. Dies könnte es Hackern ermöglichen, die Kreditkarte eines Benutzers, seine Anmeldeinformationen oder alles andere, was an den Anwendungsserver gesendet wurde, zu stehlen. Selbst wenn der Server selbst sicher ist, kann ein Hacker, der den unsicheren Kanal zwischen ihm und den Benutzern überwacht, nahezu uneingeschränkten Zugriff auf viele Informationen erhalten.
Der zweite Punkt, der oft ungeschützt bleibt, ist die Transportschicht zwischen einer Anwendung und dem Rest des Netzwerks. Beispielsweise kann ein Anwendungsserver Online-Bestellungen verarbeiten und sie dann an ein Fulfillment-System weiterleiten, oder Daten könnten einfach zur Speicherung in eine Datenbank ausgelagert werden. Wenn diese internen Kanäle ungeschützt sind, können interne Benutzer diese Informationen möglicherweise sehen.
Es ist zwar schön zu glauben, dass alle internen Benutzer gute Menschen sind, aber Tatsache ist, dass Insider-Bedrohungen in vielen Branchen zunehmen. Insider wurden dabei erwischt, wie sie im Gegenzug für das Sammeln vertraulicher Informationen für Angreifer oder Konkurrenten Bestechungsgelder annahmen. Und der Zugang zu so etwas wie Tausenden von gültigen Kreditkarten könnte für manche Menschen einfach zu verlockend sein, um sie zu ignorieren.
Was die Angriffstechniken angeht, ist es nicht sehr schwierig, ungeschützte Kommunikation abzufangen. Selbst Hacker auf niedriger Ebene wissen, wie man Man-in-the-Middle-Angriffe gegen unverschlüsselte Datenströme durchführt. Wenn sie es nicht tun, gibt es Videos im Internet, mit denen sie in weniger als einer halben Stunde geschult werden können.
Warum sind Sicherheitslücken beim unzureichenden Schutz der Transportebene so gefährlich?
Ein unzureichender oder nicht vorhandener Schutz auf den Transportebenen ist gefährlich, da es Hackern so extrem leicht fällt, vertrauliche Informationen zu sammeln. Sie müssen nicht in Ihren App-Server einbrechen oder Ihr Netzwerk hacken. Sie richten einfach einen Man-in-the-Middle-Angriff ein und lesen alles, was von Benutzern an einen Server gesendet wird. Dazu können Benutzernamen und Passwörter gehören, mit denen die Sicherheit in Zukunft mithilfe gültiger Anmeldeinformationen umgangen werden kann. Je nach Anwendung können dazu auch Kreditkarteninformationen oder andere persönliche Daten von Benutzern gehören.
Und es ist wichtig zu beachten, dass all dieses Schnüffeln außerhalb Ihres Netzwerks stattfindet. Wenn Sie unsichere Transportkanäle verwenden, können Sie nicht feststellen, ob jemand diese Informationen erfasst. Normalerweise ist das erste Anzeichen, wenn viele Benutzer anfangen, kompromittierte Konten oder Kreditkartenkäufe zu melden, und der gemeinsame Faktor ist, dass Ihre Bewerbung "kein guter Ort dafür ist. Hacker können auch Informationen ändern, sobald sie sie haben. So können sie beispielsweise die Lieferadresse ändern oder sogar bösartige Skripte in die Serverantwort einfügen, bevor sie sie an die Benutzer weitergeben.
Im Backend werden Daten durch das Versäumnis, die Transportebene zu sichern, Insidern zugänglich gemacht. Es ist wahrscheinlich viel weniger wahrscheinlich, dass ein Insider die Transportebene ausspioniert als Hacker von außen, die dasselbe tun. Aber es ist auch gefährlicher, wenn es passiert, da die Insider-Bedrohung nicht nur die Benutzerdaten, sondern auch alle vom App-Server hinzugefügten proprietären Informationen sehen kann, bevor sie diese Pakete versendet.
Beseitigung unzureichender Sicherheitslücken beim Schutz der Transportebene
So gefährlich ein unzureichender Schutz der Transportschicht auch sein mag, es ist auch nicht unglaublich schwierig, alle Transportkanäle ordnungsgemäß abzusichern. Es beginnt mit der Backend-Infrastruktur. Dies sollte ausschließlich HTTPS sein. Achten Sie darauf, HTTPS und HTTP auf einer Website nicht zu vermischen. Schließlich sollten Sie ein gültiges SSL-Zertifikat mit einer Mindestschlüsselgröße von 2048 Bit beibehalten und gleichzeitig alle Benutzer dazu zwingen, über gesicherte Browser mit HTTP Strict Transport Security (HSTS) zu interagieren.
Sobald die Infrastruktur eingerichtet ist, sollten Entwickler ein starkes Protokoll verwenden, um die Transportschicht zu schützen. Idealerweise sollte TLS 1.2 verwendet werden, obwohl TLS 1.1 und 1.0 auch akzeptabel sind, wenn dies unbedingt erforderlich ist. Sobald dies geschehen ist, sollten schwache Protokolle wie SSLv2 vollständig deaktiviert und niemals unterstützt werden.
Es sollte auch darauf geachtet werden, dass kryptografische Chiffren im Backend ausreichend leistungsfähig sind. Idealerweise sollte die Mindestgröße des Sitzungsschlüssels 128 Bit betragen. Wie bei Protokollen sollte die Unterstützung für schwache kryptografische Algorithmen wie DES und RC4-40 deaktiviert werden. Und schließlich sollten Sie eine Anwendung erst dann als wirklich sicher betrachten, wenn sowohl der Server selbst als auch alle Datenpfade, die in ihn hinein und aus ihm heraus führen, ausreichend geschützt sind.
Weitere Informationen zu Sicherheitslücken beim unzureichenden Schutz der Transportebene
Für weitere Informationen können Sie sich die OWASP ansehen Leitfaden zum Schutz Transportschichten. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.
Table des matières
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.

Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.




%20(1).avif)
.avif)
