In dem dritten Teil der Blogserie „IT Security in Web Anwendungen“ thematisieren wir das Thema Sessions, Session Hijacking und Best Practices zur Prävention dieser Art von Sicherheitsrisiken. Anhand konkreter Beispiele – in Java, PHP und Python – wollen wir die wichtigsten Punkte im Bezug auf IT-Security aufzeigen und Best Practices auflisten.
In unserem ersten Post dieser Blogserie sind wir das Thema „Injections“ angegangen und haben gezeigt, wie diese zustandekommen bzw. zu verhindern sind. Falls noch nicht geschehen empfehlen wir Ihnen Teil I der Blogserie „IT Security in Web Anwendungen – Injections“. In dem zweiten Teil der Serie sind wir auf File Up-/Download und Storage eingegangen und haben allgemeine Sicherheitsrisiken sowie Prävention und Alternativen aufgelistet.
In dem kommenden Posts der Blogserie möchten wir uns tiefergehend mit den verschiedenen Bereichen der IT Security beschäftigen. In Teil 3 thematisieren wir Sessions und Session Management. In insgesamt neun Blogposts möchten wir tiefergehend auf verschiedene Szenarien eingehen, mögliche Schutzmechanismen präsentieren und diese – wenn möglich – durch praktische Beispiele demonstrieren. Nach Blogpost #9 werden wir diese Serie und weitere Tipps und Tricks als PDF zur Verfügung stellen. Sie können sich unter dem nachfolgenden Formular zum Newsletter anmelden, um das PDF zu erhalten:
[newsletters_subscribe form=3]
Session Management in Web Anwendungen
Das Web um HTTP ist ein zustandsloses Protokoll. Dies bedeutet, dass jede HTTP Anfrage – egal ob über den Browser, API-Anfragen mit z.B. curl oder Standards wie SOAP – die Anfragenden jedes Mal authentifizieren und autorisieren muss, bevor eine Operation ausgeführt wird (z.B. Daten auflisten oder modifizieren).
Sessions – zu Deutsch: „Sitzungen“ – sind etablierte und beliebte Werkzeuge um Zustände einer Web Anwendung (z.B. der Warenkorb eines Webshops oder die Information darüber, ob die Benutzenden eingeloggt sind) über Anfragen hinweg zu speichern. Meist werden Sessions in Session Cookies gespeichert – dies ist aber kein Muss und es können auch andere Wege zum Einsatz kommen. Durch die weite Verbreitung von Cookie-basierten Sessions fokussieren wir uns nachfolgend auf diese.
Wenn mit Cookies gearbeitet wird, muss bedacht werden, das grundsätzlich sehr wenige Restriktionen im Bezug auf Cookies gelten. So darf das Cookie z.B. nicht eine bestimmte Größe überschreiten, sehr wohl jedoch über unsichere Verbindungen mit HTTP übertragen, von Javascript-Anwendungen ausgelesen und die Session ID als GET Parameter verschickt und somit als Teil der URL gemacht werden. Moderne Webserver und Programmiersprachen bieten Möglichkeiten diese „Freiheiten“ stark einzuschränken bzw. zu verbieten. Diese Einstellungen sind dringendst zu empfehlen, da sie maßgeblich zu der Sicherheit der Anwendung beitragen und einen großen Anteil von Attacken verhindern können bevor sie auftreten.
Session Cookies
Für herkömmliche Web Anwendungen sind Session Cookies eine einfache und flexible Möglichkeit den Zustand der Anwendung zu speichern. Das HTTP Protokoll ist dank seines Aufbaus in u.a. Header und Body sehr einfach erweiterbar. Cookies sind Teil des HTTP Headers und wurden 1997 mit RFC2109 standartisiert.
Dabei ist der allgemeine Ablauf von Session Cookies wie folgt:
- Webserver erzeugt eine Session und eine zugehörige ID
- bei jeder HTTP Anfrage wird die Session ID zu dem Client geschickt
- der Client schickt bei jeder Anfrage die Session ID zurück
- Webserver authentifiziert/autorisiert Benutzer bzw. Operation
Die Session ID spielt in diesem Szenario eine kritische Rolle, denn sie ist zuständig für das Zuordnen von Anfrage und Session. Kommt diese abhanden, kann dem Server eine falsche Identität vorgetäuscht werden und im Worst-Case Daten eingesehen oder Aktionen ausgeführt werden, zu denen die Angreifenden nicht befugt sind. Beispielsweise verwenden Java Servlets bzw. Java Server Pages (JSP) den Parameter JSESSIONID und PHP nutzt PHPSESSIONID. Hier stellt sich auch schon das erste kritische Sicherheitsrisiko dar: in früheren Versionen von PHP konnte der Parameter über HTTP GET ausgetauscht werden. Dies bedeutet, dass die Session ID Teil der URL war, was wiederum dazu führte, dass die Session ID in Logfiles auftaucht oder die URL leichtsinnig mit anderen Personen geteilt wurde.
Session Hijacking und mögliche Angriffsszenarien
Session Hijacking ist eine spezielle Art von böswilligen Attacken auf eine Web Anwendung, bei denen Angreifende die Session ID von Benutzenden entwenden. Diese Session ID wird an den Server gesendet, der sie authentifiziert und bestimmte Operationen auf einen Datensatz autorisiert. Session Hijacking kann durch einen XSS-Angriff erfolgen oder wenn Angreifende (physikalischen) Zugriff auf das Dateisystem des Servers erhält, in dem Sessiondaten gespeichert sind.
Die gängisten Arten von Session Hijacking Attacken sind:
- Cross-Site Scripting (XSS):
Wenn die Web Anwendung Benutzereingaben nicht richtig validiert, den Input von z.B. böswilligen JavaScript-Code bereinigt und „wie erhalten“ als HTML ausgibt, spricht man von einer Cross-Site Scripting (kurz XSS) Attacke. Die Angreifenden setzen bei diesem Angriffsszenario auf die fehlenden oder nicht ausreichenden Sicherheitsmechanismen von Benutzereingaben bzw. einer zu losen Konfiguration des Webservers (also der fehlenden Zugriffsrestriktion auf Cookies durch JavaScript). Die so erbeutete Session ID wird an die Angreifenden übertragen und diese können sich dann gegen die Web Anwendung als Benutzende authentifizieren, die sie nicht sind.
- Session Sidejacking:
Werden Daten zwischen Client und Server nicht über HTTPS übertragen oder befinden sich Benutzende in einem öffentlichen, nicht gesicherten Netzwerk kann es dazu kommen, dass Angreifende den Datenverkehr mitlesen und somit in den Besitz der Session ID gelangen.
- Session Fixation:
Die Session ID sollte nur kurz gültig sein und neugeneriert werden. Ist dies nicht der Fall oder akzeptiert der Server abgelaufene Session ID’s, spricht man von Session Fixation.
- Session Prediction:
In diesem Szenario haben Angreifende meist ein Grundverständnis wie Session ID’s erstellt werden und versuchen durch Trial-Error eine gültige Session ID zu generieren.
Schutz von Session Hijacking und Best Practices
Die Gefahr durch Session Hijacking kann durch einige Vorkehrungen und Konfigurationen im Webserver minimiert werden. Einige dieser Vorkehrungen ist auf die Entwicklung zurückzuführen, was bedeutet, dass früh in der Entwicklung der sicherheitsrelevante Aspekt der Web Anwendung berücksichtigt werden muss. Dies ist meist nicht einfach, denn viele Entwickler haben nur wenig bis gar kein Verständnis für Sicherheit in der Anwendungsentwicklung. Viele Firmen setzen daher eigens Security-Teams auf und lassen Source Code und Infrastruktur auf kritische Sicherheitslücken testen (z.B. durch Source Code Audits oder Penetrationstests). Das Verringern bzw. Verhindern des Schadens der o.g. Attacken kann wie folgt minimiert werden:
- Cross-Site Scripting (XSS):
Viele Web Frameworks der jeweiligen Programmiersprache schaffen Abhilfe bei dem Verhindern von XSS-Attacken. Für JSP gibt es beispielsweise das JSTL (Jakarta Standard Tag Library) zum Bereinigen oder Entwerten (Englisch: Escaping) von Benutzereingaben. Das Laminas Framework (früher Zend Framework) für PHP bietet Laminas-Escaper und das Flask Framework für Python hat Built-In Tools zur Präventation von XSS. Der Kerngedanke dabei ist immer derselbe: das Entfernen oder zumindest Entwerten von Steuerzeichen wie z.B. < ' ". Sind diese Zeichen entwertet, wird dem Browser angewiesen, diese nicht mehr als Befehle zu verarbeiten. Stattdessen werden sie als einfache Zeichen interpretiert und ausgegeben.
- Session Sidejacking:
Kann in den meisten Fällen durch den Einsatz von SSL und der Ende-zu-Ende Verschlüsselung der Kommunikation verhindert werden. Allerdings besteht in manchen Szenarien auch dann noch die Möglichkeit, das Session-Cookie zu entwenden. Wird bspw. die Website mit einer gültigen Session (also einer Session ID in einem Cookie) über das unsichere HTTP besucht, wird die Session ID Teil des HTTP Headers an den Server übertragen. Zwar würde der Server mit einem HTTP 301 antworten und die Benutzenden auf HTTPS umleiten, doch würde die erste Anfrage über HTTP den Angreifenden schon ausreichen die Session ID zu entwenden. Dies kann durch Einstellungen im Webserver bzw. dem Browser, Cookies nur über HTTP zu übertragen, verhindert werden.
- Session Fixation:
Tritt meist in den Fällen auf, in denen Benutzende dazu gebracht werden, vordefinierte Session IDs zu verwenden – meist in dem Kontext, bei dem die Session ID Teil der URL ist. Eine andere Möglichkeit ist ein verstecktes Formularfeld in einem vom Angreifenden erstellten Formular, mit dem das Opfer dazu gebracht wird, sich über dieses Formular anzumelden. Das Formular würde dann die Daten an die Angreifenden weiterleiten.
- Session Prediction:
Kann durch kontinuierliche Neugenerierung der Session ID verhindert werden. Dies mindert auch den Zeitrahmen für Angreifende Schaden anzurichten. Verfallen Session ID’s bspw. nach wenigen Minuten, kann evtl. Schaden gar nicht erst entstehen.
Skalierende Anwendungen und (Session) Cookies
Die oben beschriebenen Angriffsszenarien sind die gängigsten Angriffe im Zusammenhang mit Sessions und Cookies auf Web Anwendungen. Zwar wurden sie bisher nur in einem „einfachen“ Szenario mit einem Backend-Server vorgestellt, die Angriffsmöglichkeiten sowie deren Prävention gelten aber auch für den Einsatz mehrerer Backend-Server. Meist sind Entwickler und Administratoren vor weiteren, teils kombinierten Herausforderungen gestellt.
Ein Aspekt dabei ist das Session Cookie: Für Anwendungen mit einem Backend-Server ist das Cookie-basierte Session Management (bzw. Cookie im Allgemeinen) eine einfache und gängige Lösung, die mit richtiger Sicherheits-Konfiguration verlässlich funktioniert. Wenn die Anwendung aber skalieren und um mehrere Backend-Server erweitert werden soll, werden Cookies meist zu einer Herausforderung. Der Benutzer müsste entweder immer auf den selben Backend-Server kommen, oder Session Cookies müssten auf einer gemeinsamen Instanz aufbewahrt werden (z.B. eine Redis-Datenbank) oder es kommt ein ganz anderes Verfahren zum Einsatz, welches die Session allen Backend-Servern bekannt macht.
Abschließend wollen wir noch erwähnen, dass Cookies als Teil des HTTP Headers nur eine Möglichkeit sind Daten zwischen Client und Server auszutauschen. Etags bspw. werden verwendet, um die neueste Version der vom Client geladenen Seite zu prüfen und eine im Cache gespeicherte Version zurückzugeben, wenn der vom Client gesendete etag-Header nicht veraltet ist. Aufgrund ihrer Beschaffenheit sind Etag-Header für einen Browser (eine Session) eindeutig und ermöglichen somit Zustandsmanagement.
IT Security mit Ucar Solutions
Wir bieten Ihnen vollumfänglichen Source-Code Audit zum Absichern Ihrer Anwendung gegen eine Vielzahl potenzieller Sicherheitsrisiken und weiteren sicherheitsrelevanten Aspekten. Durch automatisierte und manuelle Prozesse helfen wir Ihnen, Ihre sensiblen und geschäftskritischen Informationen zu schützen und die geltenden Gesetze einzuhalten.
Unsere automatisierten Tests beinhalten u.a. Penetrationtests, toolbasierte Codeanalyse und -dokumentation. Darauf aufbauend analysieren wir den Source-Coden persönlich, versuchen die Architektur zu verstehen und mögliche Probleme bzw. Vorschläge in dem Zusammenhang zu identifizieren bzw. unterbreiten.
Des Weiteren agieren wir auch als „Software-as-a-Service“ (kurz SaaS) Vendor und bieten Ihnen verschiedene Teil- oder Vollkomponenten als Software-Service an, welche vollumfänglich, unter Berücksichtigung aller o.g. sicherheitsrelevanten ununterbrochen zur Verfügung stehen. So können Sie sich um Ihre Anwendung kümmern während wir Teilbereiche zur Verfügung stellen.
Kontaktieren Sie uns heute noch für ein unverbindliches Erstgespräch. Wir freuen uns darauf!
