Sichere Programmierung von Web-Anwendungen - Session-Hijacking

Hinzugefügt am 21.12.2020 von Frank Hissen

Zahlreiche erfolgreiche Angriffe auf bekannte Web-Anwendungen finden wöchentlich Einzug in einschlägige Medien. Grund genug bei der Entwicklung eigener Anwendung - egal ob zur rein internen Nutzung oder mit öffentlichem Zugang - sich mit den Hintergründen der "Web Application Security" zu beschäftigen.

Dies ist ein Auszug aus dem Buch "Sicherheit von Web-Anwendungen: Für Software-Entwickler und Software-Projektleiter", auch als eBook erhältlich
Es ist ebenfalls ein zugehöriger Online-Kurs erschienen: Onlinekurs Sicherheit von Web-Anwendungen, auch verfügbar auf Udemy, und als HTML5/SCORM/mit Audiokommentar auf Anfrage

In diesem Artikel geht es um den programmatischen Schutz von Sitzungen bei Web-Anwendungen. Eine sichere Konfiguration der Middleware (wie z.B. SSL/TLS), die eine Grundvoraussetzung ist, ist nicht Bestandteil dieses Artikels.

Beschreibung

Wesentliches Ziel eines Angreifers bei Session-Hijacking ist die Kopie oder Übernahme einer Nutzersitzung an einer Web-Anwendung. Dabei spielen die Authentifizierungsdaten des Nutzers keine Rolle.

Bekanntermaßen wird nach dem erfolgreichen Login in eine Web-Anwendung eine Sitzung/Session erzeugt. Damit können alle weiteren Aktionen von einem bestimmten Client-Computer einem bestimmten Nutzer zugeordnet werden. Die gängige Technik eine Session mit einem Client zu verknüpfen ist die Erzeugung und Übertragung von Session-IDs.

In der Praxis hat sich hierzu der Einsatz von Cookies durchgesetzt und wird im Allgemeinen auch als sicherste Variante (unter Berücksichtigung entsprechender Sicherheitsregeln/folgend) betrachtet. Eine Alternative wäre die Übertragung als URL-Parameter, was jedoch Session-Daten z.B. in der Browser-History zurücklässt.

So einfach dieser Mechanismus ist, so einfach lässt sich eine Session auch durch einen Angreifer übernehmen - alleine das Erlangen der Session-ID genügt. Damit kommt der Angreifer an alle Transaktionen des eigentlichen Nutzers, sofern keine neue Authentifizierung erforderlich ist. Daher dürfen Anwendungen auch keine Passwörter im Klartext anzeigen oder Passwortänderungen ohne die Angabe des alten Passworts akzeptieren. Der Schaden wäre in diesem Falle noch größer, da ein Angreifer permanenten und ggf. unentdeckten Zugriff auf den Nutzeraccount erhalten könnte.

Sichere Programmierung:

Zur sicheren Realisierung von Sessions unterscheidet man zwischen Maßnahmen bzw. Vorgehensweisen einerseits (1) und technischen Anforderungen andererseits (2).

1) Maßnahmen/Vorgehensweisen

1. Es muss eine grundsätzliche Business-Entscheidung getroffen werden, ob Sessions/Cookies nicht verfallen sollen (permanent) oder nur temporär gültig sind. Entsprechend müssen dann Session-IDs verwaltet bzw. Cookies gesetzt werden.
   → Dabei muss berücksichtigt werden, in welchem Kontext die Web-Anwendung genutzt wird. Bei einer Intranet-Anwendung, die beispielsweise in einer Shared-Computer-Umgebung genutzt wird, ist es ratsam, dass Cookies mit dem Schließen des Browsers gelöscht werden (temporäre Cookies).
2. Bei lange gültigen Sessions ist eine erneute Authentifizierung (mindestens Passwort-Eingabe) bei kritischen Transaktionen erforderlich.
3. Beim Ablauf einer Session werden Session-IDs und Cookies sowohl server- als auch clientseitig invalidiert.
4. Der Nutzer muss jederzeit die Gelegenheit haben, eine Session zu beenden, also sich abzumelden.
5. Es wirkt sich positiv auf die Sicherheit aus, wenn Nutzern offene Sessions unter ihrem Account-Namen angezeigt werden. Dazu ist eine Funktion nützlich, die es dem Nutzer direkt erlaubt, andere Sessions zu beenden.
   → Ggf. kann es in bestimmten Anwendungsfällen sinnvoll sein, überhaupt nur eine Session je Account zu erlauben.
6. Eine Verknüpfung von Client-IP-Adresse und Session-ID kann eine zusätzliche Sicherheitsmaßnahme sein, ist aber nicht zwingend erforderlich bzw. kann in bestimmten Kontexten sogar eher hinderlich sein - etwa wenn es zu einem planmäßigen IP-Adresswechsel kommt.

2) Technische Anforderungen

Session-IDs müssen folgende Anforderungen erfüllen:

1. Die Session-ID muss eine Mindestlänge von 120 Bit aufweisen
2. Session-IDs sollten in Cookies gespeichert werden
3. Session-IDs müssen für jedes Login individuell erzeugt werden

Werden Cookies zur Speicherung der Session-ID verwendet, gelten folgende Anforderungen:

1. Das Cookie-Flag "secure" muss gesetzt sein
   → Sicherstellung der ausschließlich verschlüsselten Übertragung
2. Das Cookie-Flag "httponly" muss gesetzt sein
   → Sicherstellung, dass über JavaScript kein Zugriff möglich ist (z.B. bei eventuellen XSS-Lücken)
3. Das Cookie-Flag "path" muss so restriktiv wie möglich gesetzt sein
   → Falls mehrere Anwendungen auf dem gleichen Host, aber in unterschiedlichen Verzeichnissen betrieben werden
4. Das Cookie soll soweit möglich auf einer Domain beschränkt bleiben (Header "Set-Cookie")
   → Falls mehrere Anwendungen unter Subdomains betrieben werden

Schlagworte

Session-Hijacking, Session-Security, Cookie-Security, Secure Code, OWASP, IT-Security, Sichere Programmierung, Web-/Anwendungssicherheit, IT-Securitymanagement, Security Awareness

Kategorien: IT-Sicherheit Hintergrundartikel Programmieren/Java

---

Kommentare

Eigenen Kommentar hinzufügen

Teilen / Weiterempfehlen

Wenn Sie diese Seite gut finden, teilen Sie es doch ihren Kontakten mit:

reddit Digg StumbleUpon XING
WhatsApp Telegram