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?

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.

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.

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:

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.

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. 

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.

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.

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.

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.

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:

• Gelddiebstahl: Angreifer erlangen die Fähigkeit, finanzielle Transaktionen im Namen des Nutzers durchzuführen. Dazu können Überweisungen von einem Bankkonto oder Einkäufe mit gespeicherten Zahlungsinformationen gehören.
  
• Identitätsdiebstahl: Angreifer verschaffen sich unbefugten Zugang zu sensiblen persönlichen Informationen, die in Konten gespeichert sind und die sie nutzen können, um die Identität eines Opfers über die Grenzen der gehackten Website/Anwendung hinaus zu stehlen.
• Datendiebstahl: Angreifer können jede Art von sensiblen persönlichen oder organisatorischen Daten, die sich in der Anwendung befinden, stehlen und diese Informationen nutzen, um dem Opfer oder der Organisation zu schaden (z. B. im Fall von Erpressung) oder um ihre Ziele zu verfolgen (z. B. im Fall des Verkaufs geschützter, potenziell wettbewerbsfähiger Informationen oder geistigen Eigentums).
  
• Zugriff auf zusätzliche Systeme durch SSO: Angreifer können sich auch unbefugten Zugriff auf weitere Systeme verschaffen, wenn SSO aktiviert ist, wodurch sich das potenzielle Risiko eines Session-Hijacking-Angriffs weiter erhöht. Dieses Risiko ist besonders wichtig für Unternehmen, von denen viele inzwischen SSO für Mitarbeiter aktivieren. Letztendlich bedeutet dies, dass selbst stark geschützte Systeme mit stärkeren Authentifizierungsprotokollen und weniger vorhersehbaren Sitzungscookies, wie z. B. solche, die Finanz- oder Kundendaten enthalten, nur so gut geschützt sind wie das schwächste Glied im gesamten System.

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

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. 

Es gab mehrere bemerkenswerte Fälle, in denen Angreifer Sitzungspiraterie betrieben, um in private Videositzungen einzudringen. Zu den am häufigsten gemeldeten Fällen gehörten solche, in denen sich die Angreifer durch Schimpfworte, hasserfüllte Sprache und das Teilen pornografischer Bilder zu erkennen gaben. Als Reaktion darauf haben Unternehmen wie Zoom einen stärkeren Schutz der Privatsphäre eingeführt, z. B. Passwörter für Sitzungen und Warteräume, so dass die Gastgeber von Sitzungen ihre Gäste manuell zulassen können.

Im Jahr 2010 veröffentlichte Mozilla Firefox eine Browsererweiterung namens Firesheep, die eine Sicherheitslücke für Personen, die den Browser in öffentlichen, unverschlüsselten WLAN-Netzwerken verwenden. Die Firesheep-Erweiterung machte es Angreifern leicht, die Sitzungscookies dieser Nutzer von jeder Website zu stehlen, die sie zu ihren Einstellungen im Browser hinzugefügt hatten. Schließlich reagierten viele Websites, um sich gegen dieses Risiko des Session-Hijacking zu schützen, indem sie sichere HTTP-Verbindungen (HTTPS) verlangten.

Im Jahr 2019 hat ein Forscher auf einer Bug Bounty-Plattform eine Sicherheitslücke in Slack gefunden. die es Angreifern ermöglichte, Benutzer in gefälschte Sitzungsumleitungen zu zwingen und dann ihre Sitzungscookies zu stehlen, wodurch die Angreifer letztlich Zugriff auf alle in Slack geteilten Daten erhielten (was für viele Unternehmen eine ganze Menge ist). Slack hat schnell reagiert und die Schwachstelle innerhalb von 24 Stunden nach der Entdeckung durch den Forscher gepatcht.

Im Jahr 2017 hat ein Sicherheitsforscher eine Sicherheitslücke in GitLab fest, bei der die Sitzungs-Tokens der Benutzer direkt in der URL verfügbar waren. Bei näherer Betrachtung stellte der Forscher fest, dass GitLab auch dauerhafte Sitzungs-Token verwendete, die nie abliefen, d. h., wenn ein Angreifer einmal ein Sitzungs-Token erhalten hatte, konnte er es verwenden, ohne sich um den Ablauf zu kümmern.

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.

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.

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.

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.

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.

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.

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.

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.