Was ist Sitzungsentführung und wie können Sie sie stoppen?

Diese Geschichte richtet sich an Anfänger und alle, die ein grundlegendes Verständnis für Cookies (Sitzungscookies) haben, sich aber nicht sicher sind, wie sie ordnungsgemäß gesichert werden sollen. Sie müssen kein Sicherheitsexperte sein, um dies zu tun. Sie müssen nur den Prozess verstehen und dann werden Sie es wissen.

Wenn Sie keine Ahnung haben, wie Cookies funktionieren oder wie sie funktionieren, lesen Sie bitte diesen Artikel über HTTP-Cookies.

Lasst uns anfangen! Sie haben eine erstaunliche Webanwendung, die einen großartigen Service für Kunden bietet. Das bedeutet, dass Sie über einen Authentifizierungsmechanismus verfügen, um den Benutzer zu Ihrer Anwendung zu bringen. Sie wissen, wie wichtig Sicherheit ist. Sie haben während der Authentifizierung alle möglichen Sicherheitsmaßnahmen implementiert. Toll!

Nach erfolgreicher Authentifizierung müssen Sie eine Sitzung für diesen Benutzer erstellen . Dies bedeutet, dass Sie tatsächlich ein Cookie erstellen und es an den Browser zurücksenden. In einer Java-Webanwendung heißt sie beispielsweise standardmäßig JSESSIONID. Es sieht ungefähr so ​​aus:

Mithilfe dieses Cookies kann nur Ihr Webserver erkennen, wer der Benutzer ist, und er stellt den Inhalt entsprechend bereit. Und dieser Keks sieht toll aus. Keine vertraulichen Informationen im Cookie, nur die zufällige ID (nicht zu erraten). Der Benutzer ist also sicher! …richtig?

Nun, nicht genau, schauen wir uns das genauer an.

Dieses Cookie enthält zwei Eigenschaften: HttpOnly (HTTP) und Secure. Ihre Werte sind leer, was bedeutet, dass sie für dieses Cookie nicht aktiviert sind . Dort kommt es zu dem Punkt, dass es nicht mehr sicher ist.

Hier kommt Session Hijacking ins Spiel.

Session - Hijacking , manchmal auch als Cookie bekannt Hijacking ist die Nutzung einer gültigen Computersitzung - manchmal auch genannt Sitzungsschlüssel - die unbefugten Zugriff auf Informationen oder Dienste in einem Computersystem zu erlangen. - Wikipedia

Es geht also darum, die Sitzungs-ID eines Kunden zu stehlen, mit der er auf Ihre Webanwendung zugreifen kann, als wäre er dieser Kunde.

Ist das möglich? Wie erhalten sie die Sitzungs-ID, die sich im Browser des Benutzers befindet?

Ja es ist möglich. Die beiden Cookie-Eigenschaften (oder Flags), die wir zuvor gesehen haben ( HttpOnly und Secure ), sind der Grund dafür.

HttpOnly Flag

HttpOnlyCookies sind für die JavaScript- Document.cookieAPI nicht zugänglich . Sie werden nur an den Server gesendet. Beispielsweise müssen Cookies, die serverseitige Sitzungen beibehalten, für JavaScript nicht verfügbar sein, und das HttpOnlyFlag sollte gesetzt sein.

Wenn Sie also das httpOnly-Flag nicht setzen, kann Ihr Cookie im Front-End-JavaScript-Code gelesen werden.

Öffnen Sie eine Webseite, für deren Cookie das httpOnly-Flag nicht gesetzt ist. Öffnen Sie dann die Chrome Dev Console und tippen Sie auf die Registerkarte "Konsole" (Befehlstaste + Umschalttaste + J oder Strg + Umschalttaste + J). Geben document.cookieund Geben Sie, und Sie werden etwas sehen:

Wie Sie sehen können, erhalten Sie alle Cookie-Informationen. Ein JavaScript-Angreifer kann dies einfach zur späteren Verwendung auf seinem eigenen Server veröffentlichen.

Sie fragen sich vielleicht, wie sie diesen Code in Ihre Anwendung schreiben können. Es ist auf verschiedene Arten möglich.

Eine Möglichkeit besteht darin, eine nicht vertrauenswürdige JS-Bibliothek eines Drittanbieters wie Protokollierung, Hilfsprogramme usw. einzuschleusen. Lesen Sie diesen Artikel Ich sammle Kreditkartennummern und Kennwörter von Ihrer Website. Hier ist , wie .

Eine andere Möglichkeit ist die Verwendung eines Cross Site Scripting Attack . Wir werden nicht auf die Details eingehen, aber denken Sie daran, dass dies möglich ist.

Wie können wir das beheben?

Das Sitzungscookie muss nicht einmal für den JavaScript-Client zugänglich sein. Es wird nur für den Server benötigt. Wir sollten es nur für den Server zugänglich machen. Dies kann durch Hinzufügen eines Wortes ( httpOnly ) in Ihrem http- Antwortheader set_cookie erfolgen . So was:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly

Durch Hinzufügen des httpOnly- Flags weisen Sie den Browser an, dass dieses Cookie nicht vom JavaScript-Code gelesen werden soll. Der Browser kümmert sich um den Rest. So sieht es nach dem Hinzufügen des httpOnly-Flags aus:

Beachten Sie das Häkchen in der HTTP-Eigenschaft. Dies zeigt an, dass httpOnly aktiviert ist.

Hier können Sie sehen, dass document.cookie unser Sitzungscookie nicht zurückgibt. Das heißt, kein JS kann es lesen, einschließlich externer Skripte.

Das war's - eins runter eins raus!

Sichere Flagge

Das sichere Flag weist den Browser an, dass das Cookie nur über verschlüsselte Verbindungen, dh eine HTTPS-Verbindung, an die Anwendung zurückgegeben werden soll.

Wenn also ein Cookie mit dem Flag sicher an den Browser gesendet wird und Sie über HTTP eine Anfrage an die Anwendung stellen, hängt der Browser dieses Cookie nicht an die Anfrage an. Es wird nur in einer HTTPS-Anforderung angehängt. Die HTTPS-Anforderung wird verschlüsselt, sodass Cookies sicher über das Netzwerk an Ihre Anwendung gesendet werden.

Wie kann jemand das Cookie in der HTTP-Anfrage lesen?

Dies kann erreicht werden, wenn jemand (als "Man in the Middle" -Angriff bezeichnet) den gesamten Datenverkehr im Kundennetzwerk überwacht. Sie können die Klartextdaten anzeigen, wenn die Anforderung in HTTP erfolgt.

Wenn es über HTTPS gesendet wird , werden alle Daten vom Browser verschlüsselt und an das Netzwerk gesendet. Der Angreifer kann die von Ihnen gesendeten Rohdaten nicht abrufen. Der Angreifer kann den Inhalt auch nicht entschlüsseln. Aus diesem Grund ist das Senden von Daten über SSL sicher.

Wie können wir das beheben?

Genau wie das httpOnly-Flag müssen Sie nur das sichere Flag in Ihren set_cookie- HTTP- Antwortheader einfügen . So was:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly; Secure

In Java kann dies auf verschiedene Arten erfolgen. Wenn Sie Servlet 3.0 oder höher verwenden, können Sie diese Einstellungen in web.xml folgendermaßen konfigurieren :

  true true  

Wenn Ihre Umgebung dies nicht unterstützt, können Sie es manuell hinzufügen. Mit Servlets können Sie beispielsweise Folgendes tun:

Schließlich sieht es so aus, wenn beide Flags gesetzt sind.

Fazit

Wenn Sie also mit Sitzungscookies oder anderen wichtigen Cookies arbeiten, stellen Sie sicher, dass Sie diese beiden Flags hinzufügen.

Vielen Dank fürs Lesen, Happy Securing!