Was ist Session Hijacking und wie funktioniert es?

Session-Hijacking (auch Cookie-Hijacking oder Cookie-Side-Jacking genannt) ist ein Cyberangriff, bei dem Angreifer die Computersitzung eines legitimen Benutzers übernehmen, um dessen Sitzungs-ID zu erhalten und dann als dieser Benutzer bei einer beliebigen Anzahl von Netzwerkdiensten zu agieren. Diese Art von Angriff stellt eine Gefahr für die Anwendungssicherheit dar, da sie es Angreifern ermöglicht, unter dem Deckmantel eines rechtmäßigen Benutzers unbefugten Zugriff auf geschützte Konten (und die darin enthaltenen Daten) zu erlangen.

In diesem Artikel erfahren Sie alles, was Sie über Session Hijacking wissen müssen, einschließlich

• Was ist Session Hijacking?
• Wie funktioniert das Session-Hijacking?
• Welche Arten des Session-Hijacking gibt es?
• Was ist der Unterschied zwischen Session Hijacking und Session Spoofing?
• Was sind die Risiken und Folgen von Session Hijacking?
• Was sind Beispiele für Session-Hijacking?
• Wie kann man sich vor Session Hijacking schützen?

Was ist Session Hijacking?

Jedes Mal, wenn ein Benutzer über eine HTTP-Verbindung auf eine Website oder eine Anwendung zugreift, authentifiziert der Dienst den Benutzer (z. B. über einen Benutzernamen und ein Kennwort), bevor er die Kommunikationsleitung öffnet und den Zugriff ermöglicht. HTTP-Verbindungen an sich sind jedoch "zustandslos", was bedeutet, dass jede Aktion eines Benutzers unabhängig betrachtet wird. Würden wir uns ausschließlich auf HTTP verlassen, müssten sich die Benutzer für jede Aktion oder Seite, die sie aufrufen, neu authentifizieren.

Sitzungen sind die Lösung für dieses Problem. Eine Sitzung wird auf dem Server, der die Website oder Anwendung hostet, erstellt, sobald sich ein Benutzer anmeldet, und dient dann als Referenz für die erste Authentifizierung. Im Wesentlichen können Benutzer so lange authentifiziert bleiben, wie eine Sitzung auf dem Server offen bleibt. Benutzer können eine Sitzung beenden, indem sie sich beim Dienst abmelden, oder einige Dienste beenden eine Sitzung nach einer vordefinierten Zeit der Inaktivität.

Die meisten Dienste erstellen diese Sitzungen, indem sie eine Sitzungs-ID vergeben, eine Zeichenfolge aus Zahlen und Buchstaben, die in temporären Sitzungscookies, URLs oder versteckten Feldern auf der Website gespeichert wird. In einigen Fällen werden diese Sitzungs-IDs verschlüsselt, aber das ist nicht immer der Fall. Und in vielen Fällen basieren diese Sitzungs-IDs auf vorhersehbaren Informationen, wie der IP-Adresse eines Nutzers.

Beim Session Hijacking verschaffen sich Angreifer unbefugten Zugriff auf die Sitzungs-ID eines Benutzers und können so dessen Online-Identität übernehmen. Auf diese Weise können sich Angreifer als legitime Benutzer ausgeben, Informationen erlangen und unter der angenommenen Identität Aktionen durchführen.

Wie funktioniert Session Hijacking?

Session Hijacking beginnt, wenn ein Angreifer unbefugten Zugriff auf die Sitzungs-ID eines Benutzers erhält. Angreifer verschaffen sich diesen Zugriff in der Regel, indem sie entweder das Sitzungscookie eines Benutzers stehlen (daher der alternative Name Cookie-Hijacking) oder den Benutzer dazu bringen, auf einen bösartigen Link zu klicken, der eine vorhergesagte Sitzungs-ID enthält (mehr dazu unten).

Sobald ein Angreifer die Sitzungs-ID hat und der Benutzer sich bei dem Dienst angemeldet hat, kann der Angreifer die Sitzung übernehmen. Er tut dies, indem er die Sitzungs-ID des rechtmäßigen Benutzers auf dessen Browser anwendet, was den Dienst dazu bringt, den Angreifer für den rechtmäßigen Benutzer zu halten, der an der gleichen Sitzung teilnimmt.

Unter diesem Deckmantel kann sich der Angreifer dann als rechtmäßiger Benutzer ausgeben und auf alle Informationen zugreifen oder alle Aktionen ausführen, zu denen der Benutzer berechtigt ist. In Fällen, in denen Benutzer ein Single Sign-On (SSO) haben, kann der Angreifer diesen Ansatz nutzen, um unberechtigten Zugriff auf eine beliebige Anzahl von Anwendungen zu erlangen, was die Anwendungssicherheit insgesamt stark beeinträchtigt.

Welche Arten von Session Hijacking gibt es?

Wenn man genauer untersucht, wie Session Hijacking genau funktioniert, findet man zahlreiche Möglichkeiten, diese Art von Angriff durchzuführen. Zu den Arten des Session Hijacking gehören:

1) Cross-Site Scripting (XSS)

Cross-Site-Scripting (XSS) ist eines der größten Risiken und eine der beliebtesten Methoden für Session-Hijacking. XSS tritt auf, wenn der Angreifer Schwachstellen im Zielserver oder in der Zielanwendung findet und diese ausnutzt, indem er clientseitige Skripte in die Webseite einfügt. Die Seite wird dann mit diesem bösartigen Code geladen, aber auf der Seite des Benutzers sieht alles legitim aus, da sie immer noch von einem vertrauenswürdigen Server kommt. Sobald der bösartige Code geladen ist, kann der Angreifer die Sitzungs-ID des Benutzers stehlen.

Der Angreifer könnte bei einem XSS-Angriff einen Link zu einer vertrauenswürdigen Website senden, allerdings mit veränderten HTTP-Abfrageparametern. Sobald der Benutzer auf diesen Link klickt, kann der Angreifer Zugang zu seiner Sitzungs-ID erhalten, oder in einigen Fällen kann der Link diese Informationen sogar direkt an den Angreifer senden. In solchen Fällen verwenden die Angreifer in der Regel einen URL-Verkürzer, um die URL und damit alles Verdächtige in dem Link zu verbergen.

2) Session Side-Jacking alias Session Sniffing

Session Sidejacking, auch bekannt als Session Sniffing, ist eine aktivere Form des Hijacking-Angriffs. In diesem Fall verwenden Angreifer Paket-Sniffing wie Wireshark oder Kismet, um den Netzwerkverkehr zu überwachen und Sitzungscookies nach der Authentifizierung zu stehlen. Die Benutzer sind für diese Art von Angriffen am anfälligsten, wenn der Server nur die Authentifizierungsseite verschlüsselt und nicht andere Seiten innerhalb der Sitzung. Infolgedessen können Angreifer die Sitzungs-ID nach der Authentifizierung auf den unverschlüsselten Seiten während der Sitzung erhalten.

Wichtig ist, dass Angreifer Zugang zum Netzwerk des Benutzers benötigen, um diese Art von Angriff auszuführen, was bedeutet, dass Session Sidejacking typischerweise über ungesicherte WiFi-Netzwerke oder öffentliche Netzwerke erfolgt. 

3) Fixierung der Sitzung

Sitzungsfixierung tritt auf, wenn Angreifer die Sitzungs-ID eines Benutzers festlegen können. 

Diese Art von Angriff erfordert eine Schwachstelle in der Ziel-Website, die das Setzen von Sitzungs-IDs über URLs oder Formulare ermöglicht. In diesem Fall kann ein Angreifer eine Sitzungs-ID im Namen eines Benutzers festlegen und den Benutzer dann dazu bringen, sich entsprechend anzumelden, indem er ihm entweder eine Phishing-URL sendet, die die Sitzungs-ID enthält, oder diese ID in einem falschen Anmeldeformular festlegt. 

In beiden Fällen meldet sich der legitime Benutzer bei einer Website an und authentifiziert sich mit der Sitzungs-ID, die der Angreifer festgelegt hat (und daher kennt). Sobald sich der Benutzer angemeldet hat, kann der Angreifer die Sitzungs-ID ebenfalls übernehmen.

4) Vorhersagbare Sitzungs-IDs und Brute Force

Viele Websites folgen einem Muster für die Vergabe von Sitzungs-IDs, und in einigen Fällen kann es so einfach sein, dass es die IP-Adresse des Benutzers ist. In diesen Fällen können Angreifer die ausgegebenen Sitzungs-IDs überwachen, um das Muster zu ermitteln. So können sie leicht vorhersagen, wie eine gültige Sitzungs-ID für bestimmte Benutzer aussehen könnte, und diese Sitzungs-ID für sich selbst generieren.

In ähnlicher Weise kann ein Brute-Force-Angriff erfolgen, wenn sich Angreifer Zugang zu einer Liste von Sitzungs-IDs verschaffen und diese immer wieder ausprobieren, bis eine funktioniert. In der Regel verfügen sie über eine solche Liste, wenn das Muster für die Erzeugung von IDs vorhersehbar ist. Der Unterschied besteht in diesem Fall darin, dass der Angreifer die ID eines bestimmten Benutzers möglicherweise nicht vorhersagen kann, so dass er verschiedene IDs aus der Liste ausprobieren muss, bis er eine Übereinstimmung findet.

5) Der Mann im Browser (auch bekannt als Man-in-the-Middle-Angriff oder Malware)

Bei einem Man-in-the-Browser-Angriff, der auch als Man-in-the-Middle- oder Malware-Angriff bezeichnet wird, müssen die Angreifer zunächst den Computer eines Benutzers mit Malware infizieren. 

Sobald die Malware installiert ist und sich ein Benutzer auf einer Website anmeldet, kann der Angreifer als "Man in the Middle" agieren und Informationen abfangen, die Aktionen eines Benutzers vor Ort ändern oder zusätzliche Aktionen durchführen, indem er sich als dieser Benutzer ausgibt - alles ohne das Wissen des Benutzers. Da diese Art von Angriffen vom Gerät des legitimen Benutzers ausgeht, kann es sehr schwierig sein, Verstöße gegen die Anwendungssicherheit bei dieser Art von Angriffen zu erkennen.

Mit dieser Art des Zugriffs auf das Gerät eines Benutzers können Angreifer auch direkt auf den temporären lokalen Speicherordner des Benutzers im Browser zugreifen (auch bekannt als "Cookie-Jar") und dann Sitzungs-IDs für beliebige Cookies abgreifen.

Was ist der Unterschied zwischen Session Hijacking und Session Spoofing?

Session Hijacking und Session Spoofing ähneln sich in vielerlei Hinsicht, sind aber letztlich nicht die gleiche Art von Angriff. Der wichtigste Unterschied zwischen diesen beiden Arten von Angriffen besteht darin, dass Session Hijacking stattfindet, wenn ein legitimer Benutzer in einer guten Web-Sitzung angemeldet ist. Beim Session Spoofing hingegen geben sich Angreifer als Benutzer aus, um eine neue Web-Sitzung zu starten (d. h. der Benutzer muss zu diesem Zeitpunkt nicht angemeldet sein).

Am deutlichsten zeigt sich dieser Unterschied in der Erfahrung des rechtmäßigen Benutzers. Beim Session Hijacking kann ein Angreifer, der die Sitzung unterbricht, dazu führen, dass sich die Website oder die Anwendung für das Opfer ungewöhnlich verhält oder sogar abstürzt. Da der Benutzer während eines Session-Spoofing-Angriffs nicht aktiv eingeloggt ist, wird er bei der nächsten Sitzung keine "Nebeneffekte" erleben.

Was sind die Risiken und Folgen von Session Hijacking?

Ein erfolgreicher Fall von Session Hijacking gibt einem Angreifer die Möglichkeit, alles zu tun, was der betroffene Benutzer tun kann. Dies stellt ein erhebliches Risiko für die Anwendungssicherheit dar, insbesondere wenn es darum geht, Geldtransaktionen zu initiieren, auf geschützte Daten zuzugreifen oder über SSO unbefugten Zugriff auf andere Systeme zu erlangen.

Zu den wichtigsten Risiken des Session Hijacking gehören:

• Monetary theft: Attackers gain the ability to conduct financial transactions on behalf of the user. This might involve transferring money from a bank account or making purchases with saved payment information.
  
  
• Identity theft: Attackers gain unauthorized access to sensitive personal information saved in accounts that they can use to steal a victim’s identity beyond the confines of the hacked website/application.
• Data theft: Attackers can steal any kind of sensitive personal or organizational data housed within the application and use that information to harm the victim or organization (e.g., in the case of blackmail) or to pursue their agenda (e.g., in the case of selling protected, potentially competitive information or intellectual property).
  
  
• Access to additional systems through SSO: Attackers can also gain unauthorized access to additional systems if SSO is enabled, further spreading the potential risk of a session hijacking attack. This risk is particularly important for organizations, many of which now enable SSO for employees. Ultimately, this means that even highly protected systems with stronger authentication protocols and less predictable session cookies, like those that house financial or customer information, may only be as protected as the weakest link in the entire system.

Was sind Beispiele für Session-Hijacking?

Mehrere bekannte Beispiele veranschaulichen genau, was als Folge eines Session-Hijacking-Angriffs passieren kann. Einige der bemerkenswertesten Beispiele sind:

1) "Zoom-Bombardierung"

Als die COVID-19-Pandemie ausbrach, wurde die Welt digital: Schule, Arbeit und gesellschaftliche Ereignisse wurden über Videokonferenzanwendungen wie Zoom abgewickelt. Es dauerte nicht lange, bis diese Videokonferenzen ein beliebtes Opfer für Session-Hijacking wurden und sogar den Namen "Zoom-Bombing" erhielten. 

Several notable instances occurred in which attackers engaged in session hijacking to join private video sessions. The most reported instances included those in which the attackers made themselves known by shouting profanities, hateful language, and sharing pornographic images. In response, companies like Zoom issued stronger privacy protections, such as meeting passwords and waiting rooms, so that meeting hosts could manually admit guests.

2) Mozilla Firefox-Erweiterung "Firesheep

In 2010, Mozilla Firefox released a browser extension called Firesheep that opened a vulnerability for people using the browser on public, unencrypted Wifi networks. Specifically, the Firesheep extension made it easy for attackers to easily steal these users’ session cookies from any website added to their preferences in the browser. Ultimately, many websites responded to protect against this session hijacking risk by requiring HTTP Secure (HTTPS) connections.

3) Flaute

In 2019, a researcher on a bug bounty platform found a vulnerability in Slack that would allow attackers to force users into fake session redirects and then steal their session cookies, ultimately giving the attackers access to any data shared within Slack (which for many organizations ends up being quite a lot). Slack responded quickly and patched the vulnerability within 24 hours of the researcher identifying it.

4) GitLab

In 2017, a security researcher identified a vulnerability in GitLab in which users’ session tokens were available directly in the URL. Upon digging deeper, the researcher found that GitLab also used persistent session tokens that never expired, meaning once an attacker got one session token, they could use it without the worry of expiration. 

Diese Kombination aus offener Offenlegung und dauerhaften Token stellte ein ernsthaftes Risiko dar, da sie die Benutzer für verschiedene schwerwiegende Angriffe durch Session-Hijacking über einen Brute-Force-Angriff öffnete. GitLab hat die Schwachstelle schließlich behoben, indem es die Verwendung und Speicherung dieser Token änderte.

Wie kann man sich vor Session Hijacking schützen?

Session Hijacking ist nach wie vor eine der größten Bedrohungen für die Cybersicherheit, aber es gibt mehrere Möglichkeiten, Ihr Unternehmen und seine Benutzer vor dieser Art von Angriffen zu schützen. Die besten Ergebnisse erzielen Sie, wenn Sie mehrere (wenn nicht sogar alle) dieser Ansätze zusammen anwenden, um mehrere Verteidigungslinien zum Schutz zu schaffen.

1) HTTPS verwenden

Stellen Sie sicher, dass die Websites und Anwendungen, die Ihr Team nutzt (insbesondere diejenigen, die Teil eines SSO-Universums sind), überall die Verwendung von HTTPS vorschreiben - auch über die anfänglichen Anmeldeseiten hinaus -, um in jeder Phase vollständig sichere Sitzungen zu gewährleisten. Außerdem sollten Sie sie dazu verpflichten, für alles die VerschlüsselungSSL / TLS zu verwenden, einschließlich der gemeinsamen Nutzung von Sitzungsschlüsseln. 

Diese Verschlüsselungsstufe ist die erste Verteidigungslinie zum Schutz der Sichtbarkeit von Sitzungsschlüsseln. Schließlich sollten Sie einen Standard für die Sperrung des Zugriffs auf Cookies von clientseitigen Skripten zum Schutz vor XSS-Angriffen festlegen.

2) Verlassen Sie sich auf Web-Frameworks für die Verwaltung von Sitzungscookies

Je länger und je mehr zufällige Sitzungscookies generiert werden, desto besser, denn dann sind sie schwerer vorherzusagen oder zu erraten und bieten somit Schutz vor Brute-Force-Angriffen. Der beste Weg, diese echte Zufälligkeit zu erreichen, ist die Verwendung eines Web-Frameworks zur Erzeugung und Verwaltung von Sitzungscookies, anstatt selbst ein System zu erstellen.

3) Ändern Sie den Sitzungsschlüssel nach der Authentifizierung

Der beste Schutz gegen Angriffe zur Sitzungsfixierung besteht darin, den Sitzungsschlüssel unmittelbar nach der Authentifizierung bei der Anmeldung zu ändern. 

Durch die Änderung des Schlüssels nach der Anmeldung wird sichergestellt, dass ein Angreifer, selbst wenn er den ursprünglichen Schlüssel kennt, nicht den Schlüssel kennt, der dem Benutzer für den Rest seiner Sitzung folgt. Das bedeutet, dass selbst wenn ein Angreifer den Benutzern einen Phishing-Link schickt und diese sich über diesen Link anmelden, der Angreifer mit dem generierten Schlüssel nichts anfangen kann.

4) Zusätzliche Bereiche für die Identitätsüberprüfung einführen

Das Hinzufügen neuer Bereiche für die Identitätsüberprüfung über die erste Anmeldung und den daraus resultierenden Sitzungs-Cookie hinaus kann ebenfalls eine weitere Schutzebene darstellen. 

Sie könnten zum Beispiel die IP-Adresse des Benutzers prüfen, um festzustellen, ob sie mit dem Standort früherer Anmeldungen übereinstimmt, oder das Gesamtverhalten jedes Benutzers überwachen, um Anomalien besser zu erkennen. Dieser Ansatz ist jedoch nicht perfekt: Er kann Nicht-Probleme aufzeigen, wie z. B. Fälle, in denen Benutzer häufig den Standort wechseln, und er kann tatsächliche Probleme übersehen, wie z. B. Fälle, in denen sich ein Angreifer von derselben IP-Adresse aus anmeldet, wie es der Benutzer normalerweise tut.

5) Einführung von Intrusion Detection Systems (IDS) und Intrusion Protection Systems (IPS)

IDS und IPS vergleichen den Datenverkehr einer Website mit einer Datenbank bekannter Angriffssignaturen. Wenn diese Systeme eine Übereinstimmung finden, blockieren sie den Datenverkehr und alarmieren die Systembesitzer. Die Installation dieser Systeme kann schwierig und kostspielig sein, bietet aber eine starke Verteidigungsschicht gegen Session Hijacking.

6) Timebox-Benutzersitzungen und/oder automatische Abmeldung verlangen

Schließlich sollten Sie die Einführung von Richtlinien in Betracht ziehen, die regeln, wie Benutzer Sitzungen beenden. Zwei beliebte Ansätze sind das Timeboxing von Benutzersitzungen, insbesondere nach einer gewissen Zeit der Inaktivität, und die Forderung nach einer automatischen Abmeldung, sobald das Fenster geschlossen wird. Beide Ansätze tragen dazu bei, die Zeitspanne zu minimieren, in der ein bestimmter Sitzungs-Cookie aktiv bleibt. Sobald sich ein Benutzer abmeldet, sollten Sie sicherstellen, dass das Sitzungscookie automatisch von seinem Gerät gelöscht wird, um eine zusätzliche Belastung zu vermeiden.

All it takes is one expired certificate to take down critical systems and applications. But without visibility, it’s impossible to stay ahead. Keyfactor is here to help you prevent session hijacking and system outages—get in touch with us today.