In Webanwendungen ist die Session stets ein beliebter Angriffspunkt, wodurch es immer wichtiger wird, diese Angriffsmöglichkeiten zu unterbinden. Ein Session Angriff ist eine häufige Sicherheitslücke von unausgereiften Webanwendungen.
Angreifer manipulieren hierbei die Anfragen von unwissenden Nutzern der Webanwendung, um z.B. Zugriff auf geschützte Inhalte zu erhalten. In diesem Eintrag soll dargestellt werden, wie präventiv gegen Session Stealing, Session Fixation und Session Riding vorgegangen werden kann.
Das soll dabei helfen, Ihre Anwendung sicherer zu machen und Sie auch über mögliche Lücken aufzuzeigen, die auch für Sie als Nutzer interessant sind. Wir wollen hier nur einen allgemeinen Überblick liefern. Eine Detailsuche über die bekannten Suchmaschinen hilft dann, die jeweiligen Mechanismen zum Schutz der Daten zu implementieren.
Session Stealing
Beim Session Stealing, auch Session Hijacking genannt, geht es darum, die Identität des authentifizierten Nutzers anzunehmen, indem dessen Session verwendet wird. Der Webserver ordnet jedem Nutzer einen Speicher zu, der die Session ist. Der Webserver addressiert den Speicher über eine generierte ID des Nutzers.
Liest ein Angreifer bei einer MITM- (Man In The Middle) Attacke oder einem einfachen Mitlesen des drahtlosen Datenverkehrs die Anfrage aus, kann er die Session ID verwenden, um sich Zugang zu den geschützten Inhalten und Daten zu verschaffen. Ist das Angriffsopfer bereits angemeldet und werden die Anmeldedaten werden in die Session geschrieben, ist ein Angreifer autorisiert, wenn er sich der Session ID annimmt. Das Session Stealing kann nicht über die Verwendung einer SSL-gesicherten Verbindung über das HTTPS-Protokoll erfolgen. Danach kann der Angreifer nicht mehr die Session ID auslesen, da die Anfrage verschlüsselt ist.
Ist die Anfrage verschlüsselt, ist es dennoch möglich über XSS (Cross-Site-Scripting) an den Sitzungsschlüssel des autorisierten Nutzers zu gelangen. Die Prävention von XSS erläutern wir in einem späteren Artikel.
Session Fixation
Bei der Session Fixation ist es das Ziel, als Angreifer eine Session ID zugewiesen zu bekommen, diese jedoch an einen Nutzer zu geben und zu warten, bis in die Session geschrieben wurde, dass der Nutzer autorisiert wurde. Der Angreifer hat parallel Zugriff, da er die gleiche Session ID verwendet. Die Umsetzung erfolgt so, dass der Angreifer das selbst erhaltene Cookie und somit die Session ID seiner Sitzung ausliest. Anschließend präpariert der Angreifer einen Link, der die Session ID bereits in der URL enthält. Dafür muss die Session ID in der Webanwendung bei einer POST- oder GET-Anfrage als Parameter akzeptierbar sein. Zusätzlich kann der Link selbst verschleiert werden, wenn ein URL-Shortener verwendet wird. Um dem präventiv vorzubeugen, sollte die Session ID nicht als Parameter aus der URL, sondern aus dem gesetzten Cookie verarbeitet werden. [1]
Ist es dem Angreifer nicht möglich, einem Nutzer den Link zukommen zu lassen, ist auch hier XSS möglich. Dabei wird dann eine Script-Datei auf der Webseite eingeschleust, die auf den Clients ausgeführt wird und automatisch die Session ID des Angreifers in die Cookies des Nutzers setzt. Der Angreifer kann auch hier parallel zugreifen und ist autorisiert. Dem kann man, neben der Vorbeugung von XSS, entgegengewirken, wenn man die Session ID bei jedem neuen Login neu generieren lässt und die alte ID nicht weiterverwendet. Zusätzlich können Sessions mit einer Validität versehen werden, sodass sie ablaufen und Angreifer diese nicht lange weiterverwenden können. Auch das Abmelden sollte nicht nur Daten aus der Session löschen, sondern diese auch als invalide kennzeichnen. Dementsprechend muss eine Prüfung bei der Authentifizierung eingebaut werden, der prüft, ob die Session valide und nicht abgelaufen ist. [2]
Session Riding
Ein etwas differenzierter, von den bisher genannten Angriffen, ist das Session Riding, oder auch CSRF (Cross-Site Request-Forgery) genannt. Dabei wird von einem Angreifer genutzt, dass ein Nutzer bereits autorisiert ist, beispielsweise in einem anderen Tab. Ein XSS wird in diesem Fall nicht benötigt, sondern es wird direkt auf der Seite, auf dem sich der Nutzer parallel befindet ein POST-Befehl zur anzugreifenden Webanwendung gesetzt. Dies kann z.B. über einen Link erfolgen. Klickt ein unwissender Nutzer auf diesen Link, wird der POST-Befehl ausgeführt und dadurch, dass der Nutzer bereits autorisiert ist, ist es möglich Befehle auszuführen, ohne sich neu zu authentifizieren.
Um das Session Riding zu unterbinden, verwendet man ein CSRF-Token. Bei Formularen nutzt man ein verstecktes Input-Field, das einen vom Webserver generierten String enthält, der bei der Formularübermittlung überprüft wird. Der Server stoppt die Weiterverarbeitung der Anfrage, wenn das CSRF-Token in der Anfrage des Nutzers nicht vorhanden ist. Dabei ist wichtig, dass das Token nicht direkt im HTML-Text der Website enthalten ist, sondern vom Website-Controller generiert wird und für jeden Nutzer unterschiedlich ist. Außerdem ist es wichtig, dass das CSRF-Token eine ausreichende Länge, von z.B. 16 Bytes hat, sodass es nicht erraten oder ohne weiteres über Probieren herausgefunden werden kann. [3]
Fazit – Was bedeutet das für mich?
Sie sehen, dass es viele Möglichkeiten gibt, Sicherheitslücken in Sessions auszunutzen. Neben den genannten Möglichkeiten, gibt es viele weitere, die es zu unterbinden gilt. In dieser IT-Sicherheitsreihe wollen wir Sie darüber aufklären.
Für Sie als Nutzer bedeutet das, dass Sie stets auf der Acht sein sollten und Links, die Sie erhalten untersuchen müssen. Das ist umso bedeutender, wenn Sie sich für den Inhalt auf der Seite authentifizieren müssen.
Sie wollen noch 2023 Ihre Digitalisierung voranbringen?
Dann sichern Sie sich eine kostenlose Beratung und wir analysieren auf Augenhöhe Ihre Prozesse und mögliche Potenziale.
Ihr Julius Hennig, IT-Consultant
Was bedeutet das für Sie, wenn Sie unser Kunde sind?
Wir sind stets darauf bedacht, die neuesten Sicherheitsstandards in unsere Anwendungen zu entwickeln. Die Sicherheit einer jeden Anwendung ist stets ein hohes Gut für uns. Daher entwickeln wir für alle unsere Software-Produkte ein Sicherheitskonzept oder wenden ein bei uns standardisiertes Verfahren für mögliche Sicherheitslücken an.
In unserem Team gibt es einige Experten, die sich auf die Sicherheit in (Web-) Anwendungen spezialisiert haben. In unserer Reihe zur IT-Sicherheit wollen wir unser Fachwissen weitergeben und versuchen, Leser unseres Blogs über mögliche Sicherheitslücken aufmerksam zu machen. Außerdem wollen wir über mögliche Folgen berichten, die entstehen, wenn Betreiber Sicherheitslücken ignorieren (neben rechtlichen Konsequenzen).
Sind Sie ein Betreiber einer Webseite oder einer Online-Plattform, sollten Sie sich stets über Lücken in Ihrem Sicherheitskonzept informieren. Sollten Sie als Betreiber weitere Fragen haben, kontaktieren Sie uns gern hier oder per E-Mail an info@codeguides.de. Gern können Sie uns konsultieren, wenn Sie weitere Fragen auch speziell zu Ihrer Software-Architektur haben. Wir freuen uns auf Ihre Anfrage!
[1] vgl. (Kachel, Analyse und Maßnahmen gegen Sicherheitsschwachstellen bei der Implementierung von Webanwendungen in PHP/MySQL, 2008)
[2] vgl. https://www.hacksplaining.com/prevention/session-fixation (2016, abgerufen am 05.12.2018)
[3] vgl. https://poe-php.de/sicherheit/was-ist-cross-site-request-forgery-csrf (2017, abgerufen am 03.12.2018)