Hacking im Web 2.0: Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihren Webapplikationen 9783645224680

Citation preview

---

Tim Philipp Schäfers, Jahrgang 1995, ist seit seinem Abitur als Security-Consultant tätig und berät Firmen im Bereich Websicherheit/Webhacking. Schäfers deckte gravierende Sicherheitslücken bei Unternehmen wie PayPal, Facebook, Google, der deutschen Telekom und vielen weiteren Unternehmen verantwortlich auf. Er ist Mitgründer und Mitbetreiber des Webprojekts „Internetwache.org", das sich ebenfalls mit der Sicherheit von Webapplikationen und Webhacking beschäftigt. Seit Ende 2015 schreibt Schäfers zudem auf dem Web-Portal golem.de über die Themen IT-Sicherheit und Privatsphäre.

Tim Philipp Schäfers

Hacking im Web Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihren Webapplikationen • Angriffe verstehen: Session Hijacking, Cross-Site-RequestForgery, Cross-Site-Scripting, File Inclusion, SQL-Injection, UI-Redressing und mehr • Eigene Testumgebung aufbauen und Kenntnisse direkt umsetzen • 35 Sicherheits-Tools kennenlernen und zum Aufspüren von Lücken nutzen

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar. Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unter Einschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. Der Verlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch die juristische Verantwortung oder irgendeine Haftung für Folgen, die auf fehlerhafte Angaben zurückgehen, übernehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressen oder Versionsnummern stellen den bei Redaktionsschluss verfügbaren Informationsstand dar. Verlag und Autor übernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertretenden Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen ausschließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinhabers möglich.

© 2018 Franzis Verlag GmbH, 85540 Haar bei München Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF, ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt. Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesem Werk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der Hersteller.

Autor: Tim Philipp Schäfers

Programmleitung: Dr. Markus Stäuble, Benjamin Hartlmaier Lektorat: Hans Hartings Satz: DTP-Satz A. Kugge, München art & design: www.ideehoch2.de

ISBN 978-3-645-22468-0

Vorwort Kaum ein Monat vergeht, in dem nicht bekannt wird, dass ein Unternehmen Opfer eines Hackerangriffs geworden ist. Oftmals wird die Webseite verunstaltet, Social-Media-Accounts geraten unter die Kontrolle von unbekannten Angreifern, oder es wird gar die gesamte Onlinedatenbank eines Unternehmens kopiert. Als Einstiegspunkt für Angreifer dient oft das Web, genauer die Webapplikationen, die auf Servern im Internet betrieben werden. Im Handumdrehen kann die Webseite eines Unternehmens zum Einfallstor werden oder der Webshop zur Goldgrube für Onlinekriminelle. Solche Vorgänge schaden dem Geschäft meist erheblich. Die (Un-)Sicherheit Ihrer Webapplikationen entscheidet letztlich auch über den Erfolg oder Misserfolg Ihres Unternehmens, denn oftmals findet über diese Anwendungen die Abwicklung ganzer Geschäfts(teil)prozesse statt. Genau um diese Thematik soll es in diesem Buch gehen: die Sicherheit von Webanwendungen mithilfe eines sicheren Programmcodes und sicherer Konfiguration von Webservern zu gewährleisten. Längst wird für eine sichere Webapplikation mehr benötigt als Standardlösungen oder Firewalls, vielmehr ist ein hohes Maß an Wissen nötig, um überhaupt nachvollziehen zu können, was mögliche Angreifer auf Applikationsebene alles versuchen, um Systeme zu hacken. Da verschiedene Arten von Angriffen zur Verfügung stehen, geht dieses Fachbuch auf die gängigsten

Angriffsvektoren beim Webhacking ein und versucht zu erklären, wie ihnen begegnet werden kann. Die Komplexität und das schnelle Wachstum des Webs und der damit verbundenen Technologien haben seit seiner Entstehung für einiges Durcheinander gesorgt. Dieser Wirrwarr wirkt sich auf die Sicherheit von Systemen und Webapplikationen negativ aus. Es gibt im Web Standards, die nicht eingehalten werden, gelebte Regeln (die eigentlich nur Vorschläge waren) und sicherlich auch eine Menge verzweifelter Entwickler, die sich fragen, wie sie da den Durchblick behalten können. »Hacking im Web« soll hier weiterhelfen: Es werden Angriffsmöglichkeiten aufgezeigt, zahlreiche Tipps gegeben und Vorschläge zur Behebung von Lücken gemacht, damit Sie wissen, wie auf mögliche Gefahren reagiert werden kann. Dadurch können Angriffsflächen bereits während der Architekturund Anwendungsentwicklung minimiert werden. Darüber hinaus soll Ihnen dieses Buch das notwendige Werkzeug an die Hand geben, um selbst Angriffe auf Ihre Webapplikationen zu Testzwecken durchführen zu können. In der zweiten, überarbeiteten Auflage von »Hacking im Web« wurden dazu ein Kapitel zur Einrichtung einer Testumgebung eingefügt und zudem die Nutzung von Tools stärker in den einzelnen Kapiteln berücksichtigt. Sofern Sie also selbst die vorgestellten Schwachstellen ausnutzen möchten, empfiehlt es sich, die Schritte aus Kapitel 3 zu befolgen und die in den Kapiteln vorgestellten Schwachstellen direkt selbst auszuprobieren. Neben inhaltlichen Anpassungen in den übrigen Kapiteln wurden mit Blick auf neue Technologien (Cloud-Speicher) damit verbundene Schwachstellen und sie auszunutzende Angriffsvektoren hinzugefügt.

Das frühere Kapitel zum Basiswissen (Kapitel 3 der ersten Auflage) wurde aus dem Buch entfernt. Es lässt sich mittlerweile auf der Webseite zum Buch kostenfrei abrufen: https://hacking-imweb.de/basiswissen.pdf Begleitend zum Buch wird es Kurz-Videos zum Thema Web- und ITSicherheit geben, die nach Veröffentlichung des Buches erscheinen. Um auf dem Laufenden zu bleiben, empfiehlt es sich, die Webseite zum Buch (https://hacking-im-web.de) periodisch abzurufen oder dem Autor auf Twitter zu folgen (https://twitter.com/TimPhSchaefers). Nun wünsche ich Ihnen erst einmal viel Freude bei der Lektüre und Erfolg bei der praktischen Umsetzung! Tim Philipp Schäfers, Detmold im Sommer 2018

Danksagung Dieses Buch konnte nur in dieser Form erscheinen, weil zahlreiche Personen mich in meinem Vorhaben, einiges über die Sicherheit von Webapplikationen zu Papier zu bringen, unterstützt haben. Ein großes Dankeschön für geniale Ideen, geistreiche Einfälle und alle sonstigen Formen der Unterstützung geht an meine Freunde und meine gesamte Familie. Des Weiteren gilt mein ganz besonderer Dank Rico Walde und Sebastian Neef. Beide haben mit ihrem fundierten Fachwissen und durch hilfreiche Rückmeldungen zu einzelnen Kapiteln maßgeblich dazu beigetragen, dass dieses Fachbuch hoffentlich ausgeglichene Anteile an Theorie und Praxis aufweist und noch dazu angenehm zu lesen ist. Zudem möchte ich Dr. Markus Stäuble, dem ehemaligen Lektor und Programmleiter »Professional Series« beim Franzis Verlag, danken. Seine Ausdauer, seine Anregungen und Tipps und nicht zuletzt auch die Begeisterung für das Thema haben mich als recht jungen Erstautor 2016 motiviert, das Buchprojekt durchzuführen und mit dem Buch Teil der Serie zum Thema »Hacking« im Franzis Verlag zu werden. 2018 erscheint dieses Buch in zweiter Auflage. Daran haben weitere Personen mitgearbeitet und mich unterstützt. Mein Dank gilt vor allem Benjamin Hartlmaier und dem Team vom Franzis Verlag, die

immer ein offenes Ohr hatten und mich bei der Überarbeitung des Buches tatkräftig unterstützt haben. Außerdem möchte ich Hans Hartings ganz herzlich danken, der durch seine zahlreichen Hinweise im Rahmen des Lektorats maßgeblich zur Steigerung der sprachlichen Qualität dieses Buches beigetragen hat und insbesondere in der Endphase des Projektes mir mit Rat und Tat zur Seite stand. Abschließend möchte ich Ihnen, liebe Leser, stellvertretend für eine ganze Reihe von Webnutzern danken! Das moderne Web existiert nicht ohne neugierige Entwickler, mutige Gestalter, gewiefte Blogger, clevere Hacker oder skeptische Mitleser. In der menschlichen Evolution gab es wohl kaum eine andere Kommunikations- und Verbindungsart, die so vielfältig, umfassend und allgegenwärtig war oder ist wie das Web — deshalb: Danke, dass Sie alle es täglich nutzen und es so zu dem machen, was es ist!

Inhalt 1 Einleitung 1.1 Der Ansatz 1.2 Das Ziel 1.3 Der Aufbau 1.4 Die Grenzen 1.5 Das (Kern-)Problem 2 Evolution des Webs 2.1 Die Anfänge des Webs 2.2 Die Boomphase des Webs 2.3 Webapplikationen heute 2.4 Webapplikationen in der Zukunft 2.5 Entwicklung der Websicherheit 3 Einrichtung der Testumgebung 3.1 Kali Linux herunterladen und installieren 3.2 Betriebssystem aktualisieren und Nutzer anlegen 3.3 Chromium installieren 3.4 DVWA installieren und konfigurieren 4 Session-Angriffe 4.1 Man-in-the-Middle-Angriff 4.1.1 Netzwerkverkehr mitschneiden 4.1.2 Netzwerkverkehr auswerten 4.2 Cookie-Replay-Angriff 4.3 Session-Hijacking

4.3.1 Session-Hijacking in der Praxis 4.4 Session-Fixation 4.5 Session-Riding bzw. CSRF (Cross Site Request Forgery) 4.6 Zusammenfassung: Abhilfe aus Entwicklersicht 4.6.1 Verschlüsselung 4.6.2 Sichere Generierung von Session-IDs 4.6.3 Sonstige Maßnahmen 4.6.4 Hinweise zu Session-Riding bzw. CSRF 5 Cross-Site-Scripting (XSS) 5.1 Reflexives XSS 5.2 Persistentes XSS 5.3 DOM-based XSS 5.4 self-XSS 5.5 Social-engineered XSS 5.6 uXSS 5.7 Flash-based XSS 5.8 Abhilfe aus Entwicklersicht 5.8.1 Sonstige Hinweise/Umgehen von Filtern 5.8.2 Schutz vor reflexivem und persistentem XSS 5.8.3 Schutz vor DOM-based XSS 5.8.4 Schutz vor self-XSS 5.8.5 Hinweise zu Social-engineered XSS 5.8.6 Hinweise zu uXSS 5.8.7 Schutz vor Flash-based XSS 5.9 Sonstige Maßnahmen gegen XSS 5.9.1 CSP (Content-Security-Policy) 5.9.2 XSS-Filter im Browser 5.9.3 http-only-Flags 5.10 Zusammenfassung der Maßnahmen 5.11 Wissenswertes über XSS 5.12 Scriptless Attacks 6 Angriffe auf nachgelagerte Datenbanksysteme

6.1 SQL-Injections 6.1.1 Login Bypass mit SQL-Injection 6.1.2 Basisangriffe durch SQL-Injection 6.1.3 Blind-SQL-Injection 6.1.4 Wesentliche Erkenntnisse: Angreifersicht 6.1.5 Sicherung von SQL-Datenbanken 6.1.6 Wesentliche Erkenntnisse: Entwicklersicht 6.1.7 Wissenswertes über SQL-Injections 6.2 Grundlagen von LDAP 6.2.1 Operatoren innerhalb von LDAP 6.2.2 Verknüpfung von Operatoren 6.2.3 LDAP-Injection 6.2.4 Blind-LDAP-Injection 6.2.5 Sicherung von LDAP-Systemen 6.3 XPath 6.3.1 XPath-Injection 6.3.2 Blind-XPath-Injection 6.3.3 Sicherung von XPath 6.3.4 Zusammenfassung: Sicherung nachgelagerter Dateisysteme 7 Sicherheit von Authentifizierungsmechanismen 7.1 Verschiedene Angriffsvektoren 7.1.1 Simple Angriffe gegen Authentifizierungsmechanismen 7.1.2 Wörterbuchangriff 7.1.3 Brute-Force-Methode 7.2 Grundlagen zum Passworthashing 7.3 Kryptografische Hashfunktionen 7.4 Passwortcracking 7.4.1 Lookup-Tabellen mittels Brute-Force-Methode oder Wörterbuchangriff 7.4.2 Rainbow Tables 7.4.3 Google-Suche 7.4.4 Tools

7.5 Typenunsicherer Vergleich 7.6 Abhilfe aus Entwicklersicht 7.6.1 Salt hinzufügen 7.6.2 Sicheres Passworthashing 7.6.3 Passwort-Policy 7.6.4 Passwortvalidierung 7.6.5 Sicherer Vergleich 7.6.6 Weitere Authentifizierungsarten 7.6.7 Hinweise zur Log-in-Änderung 7.6.8 Hinweise zur »Passwort vergessen?«-Funktion 7.6.9 Protokollierung (Logging) 7.6.10 Zusammenfassung 8 File Inclusion 8.1 Path Traversal 8.1.1 Abhilfe aus Entwicklersicht 8.2 Local File Inclusion (LFI) 8.2.1 Abhilfe aus Entwicklersicht 8.3 Nullbyte-Injection 8.3.1 Abhilfe zur Nullbyte-Injection 8.4 Uneingeschränkte Dateiuploads 8.4.1 Hinweis zum Upload von Dateien 8.5 Remote File Inclusion (RFI) 8.5.1 Abhilfe aus Entwicklersicht 8.6 XML-External-Entities-Injection (XXE) 8.6.1 Abhilfe aus Entwicklersicht 8.7 Code-Injection 8.7.1 Abhilfe aus Entwicklersicht 8.8 HTTP-Header-Injection 8.8.1 Cookie-Injection 8.8.2 SMTP-Header-Injection 8.8.3 Abhilfe aus Entwicklersicht 8.9 Zusammenfassung

9 Logische Fehler 9.1 Zugriffsrechte 9.1.1 Rechteausweitungen 9.1.2 Ungeschützte Funktionen 9.1.3 Kontextabhängige Zugriffe 9.1.4 Parametrisierte Zugriffskontrollen 9.1.5 Referrer-basierte Zugriffskontrolle 9.1.6 Schrittweise Zugriffskontrolle 9.2 Ungeprüfte Um- und Weiterleitungen 9.2.1 Abhilfe aus Entwicklersicht 9.3 Namenskonflikte 9.3.1 Namenskonflikte in URLs 9.3.2 Namenskonflikte in Nutzernamen 9.3.3 Namenskonflikte bei Uploads 9.4 Cookie-Manipulation 9.4.1 Abhilfe aus Entwicklersicht 9.5 Zusammenfassung 10 Informationspreisgabe 10.1 Fehlermeldungen 10.2 Directory Listing 10.3 Öffentlich zugängliche Informationen 10.3.1 Versteckte Subdomains 10.3.2 »Versteckte« Pfade/Standardpfade 10.3.3 Informationen aus dem Quelltext 10.3.4 Öffentliche Dateien 10.3.5 Öffentliche Logdateien 10.3.6 Repositories (git, svn, etc.) 10.3.7 DS_Store-Dateien 10.3.8 Sonstige Informationen 10.3.9 Unsichere direkte Objektreferenzen 10.3.10 Standardwerte 10.3.11 Suchmaschinen 10.3.12 Soziale Manipulation (Social Engineering)

10.4 Abhilfe: Informationspreisgabe 10.4.1 Abhilfe: Fehlermeldungen 10.4.2 Abhilfe: Directory Listing 10.4.3 Abhilfe: öffentlich zugängliche Informationen 10.4.4 Abhilfe: Standardwerte 10.4.5 Abhilfe: Suchmaschinen 10.4.6 Abhilfe: Phishing-Angriffe 10.4.7 Abhilfe: Social Hacking 10.4.8 Abhilfe: Social Hacking gegen Plattformbetreiber 10.4.9 Abhilfe: Social Hacking innerhalb von Plattformen 11 UI-Redressing 11.1 Die Methoden der Angreifer 11.1.1 Clickjacking 11.1.2 Cursorjacking 11.1.3 Fortgeschrittene UI-Redressing-Angriffe 11.2 Abhilfe aus Entwicklersicht 11.2.1 CSP (Content-Security-Policy) 11.2.2 X-Frame-Options (XFO) 11.2.3 Frame-Busting mittels JavaScript 11.2.4 Zusammenfassung 12 Weitere Angriffsarten 12.1 SQL-Injections zu XSS 12.2 XSS zu SQL-Injection 12.3 Domain- bzw. Typosquatting 12.4 Google-Bombing 12.5 Exploits 12.6 Rent a Hacker/Untergrundforen 13 Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche 14 Tools 14.1 Toolübersicht

14.2 Mozilla Firefox-Erweiterungen 14.2.1 New Hackbar 14.2.2 HTTP Header Live 14.2.3 User-Agent Switcher 14.2.4 Wappalyser 14.2.5 Scrippy 14.3 HTTP-Proxy-Tools 14.3.1 Burp Suite 14.3.2 OWASP Zed Attack Proxy (ZAP) 14.4 Tools zu Session-Angriffen 14.4.1 Wireshark 14.4.2 CSRFGenerator 14.5 Angriffstools zu XSS 14.5.1 XSSer 14.5.2 Xenotix XSS Exploit Framework 14.5.3 Adobe SWF Investigator 14.6 Tools zu nachgelagerten Datenbanksystemen 14.6.1 SQL-Ninja 14.6.2 sqlmap 14.6.3 Havij 14.6.4 LDAP Blind Explorer 14.6.5 XPath Blind Explorer 14.7 Angriffe gegen Authentifizierungsmechanismen 14.7.1 Brutus 14.7.2 Cintruder 14.8 Passwortcracking 14.8.1 Hash Identifier 14.8.2 findmyhash 14.8.3 John the Ripper 14.9 Tools zur Informationspreisgabe 14.9.1 Subbrute 14.9.2 Knock Subdomain Scan 14.9.3 WFuzz 14.9.4 DirBuster

14.9.5 WPScan 14.9.6 joomscan 14.9.7 GitTools (Finder, Dumper, Extractor) 14.9.8 .DS_Store Scanner 14.9.9 theHarvester 14.9.10 Social Engineering Toolkit (SET) 14.9.11 Snallygaster 14.10 Tools zu UI-Redressing 14.10.1 Clickjacking Tester 14.10.2 Jack (Clickjacking Tool) 14.11 Kommentar zu automatischen Schwachstellenscannern 15 Bug-Bounty-Programme 16 Legal Webhacking durchführen 16.1.1 HackITs 16.1.2 Capture the Flag 16.1.3 Responsible-Disclosure-Programme/Bug-BountyProgramme 16.1.4 Zusammenfassung 17 SCADA-Hacking 17.1.1 Ich sehe was, was du nicht siehst, und das bist … DU — öffentlich zugängliche Kameras 17.1.2 Zugriff auf elektronische Geräte 17.1.3 Öffentlich zugängliche Human Machine Interfaces (HMI) 17.1.4 Öffentlich zugängliche PLCs (Programmable Logic Controller) 17.1.5 Shodan — das dunkle Google 17.1.6 Fazit Epilog Abkürzungsverzeichnis

Literaturempfehlungen Quellenverzeichnis Index

1 Einleitung Webapplikationen sind im Geschäftsalltag in nahezu jedem Unternehmen allgegenwärtig: Das fängt bei einem einfachen Ticketsystem für Supportleistungen an, führt über die Firmenwebsite zu einer komplexen Webanwendung für die Bestellung der Waren durch Kunden (E-Commerce) und reicht bis hin zu sensiblen Gehaltsabrechnungssystemen. Viele Anwendungen haben heutzutage Programmierschnittstellen (APIs) mit dem Web, und auch der Austausch von Unternehmensdaten mit Dritten wird immer mehr die Regel. Was wäre, wenn plötzlich der Webshop oder die Internetseite Ihres Unternehmens für mehrere Tage nicht erreichbar wäre, oder das Banner einer Hackergruppe darauf thronte? Wie gehen Sie damit um, wenn plötzlich Ihre Kundendatenbank in ominösen Onlineforen auftaucht oder vertrauliche E-Mails in sozialen Netzwerken für einen Sturm der Entrüstung (Shitstorm) sorgen? Eines der prominentesten Beispiele für die gravierenden Folgen eines Hackerangriffs ist der Hack von Yahoo im Jahr 2013. Bei diesem Hack gelang es Unbekannten die Daten von drei Milliarden Nutzern zu kopieren [1]. Der Angriff ist ausgerechnet kurz vor dem Verkauf des Unternehmens Yahoo an Verizon bekannt geworden und hat abschließend sogar die US-Börsenaufsicht auf den Plan gerufen [2]. Das Unternehmen sollte ursprünglich für über 4,8 Milliarden US-Dollar verkauft werden – durch das Bekanntwerden des Hacks wurde der Kaufpreis von Yahoo nachträglich auf 4,48

Milliarden US-Dollar (um circa 300 Millionen US Dollar) gesenkt, und in der Folge des Hacks ist die ehemalige Chefin von Yahoo (Marissa Mayer) zurückgetreten [3]. Wie sich an dem Beispiel zeigt, kann ein Hack auf ein Unternehmen immense Auswirkungen haben, nicht zuletzt haben neben dem Betreiber vor allem auch die Nutzer dieser Applikationen unter solchen Raubzügen im digitalen Raum zu leiden. Der australische Sicherheitsforscher Troy Hunt hat eine Webseite zu Datenleaks erstellt, auf der Sie durch Eingabe Ihrer E-Mail-Adresse prüfen können, ob Sie selbst schon einmal von einem »Data Breach« betroffen waren: https://haveibeenpwned.com/

Trotz all dieser Hacks hat sich recht wenig getan, schließlich lesen wir Nachrichten zu solchen Hacks immer wieder. Umso wichtiger ist es, dass Sie sich mit Ihren Systemen beschäftigen und solchen Angriffen präventiv begegnen, indem Sie sie stärker sichern.

1.1 Der Ansatz In diesem Buch soll ganz pragmatisch gezeigt werden, wie die Programmierung einer sicheren Webapplikation möglich ist. Mittels realer Sicherheitslücken und durch Codebeispiele wird deutlich gemacht, wie schnell Hacker einer sicher geglaubten Webanwendung habhaft werden können. Um dies zu erreichen, wird immer wieder die Perspektive eines potenziellen Angreifers eingenommen und beispielsweise an Hand von Angriffen auf die Testumgebung gezeigt, welche Folgen Angriffe haben können. Dadurch soll die Bedrohung realistisch nachgeahmt und verdeutlicht werden, dass sie nicht nur durch IT-Profis realisiert werden kann, sondern durch jeden, der genug Zeit aufwendet und Interesse

aufbringt. Letzteres ist auch der Grund, weshalb es solche Angriffe täglich tausendfach gibt.

1.2 Das Ziel Für Entwickler oder IT-Sicherheitsverantwortliche ist es immer wieder sinnvoll, sich in die Lage eines Angreifers zu versetzen, um die eigene Anwendung besser gegen Angriffe zu schützen. Ziel des Buchs ist also die Schaffung eines Bewusstseins dafür, dass jeder geschriebene Code zum Einfallstor werden kann, wenn man ihn nicht so genau und korrekt implementiert wie notwendig. Das Buch zielt darauf ab, dass Sie um die Ecke zu denken lernen und noch nicht zufrieden sind, wenn eine Funktionalität wie gewünscht implementiert wurde, sondern erst, wenn sie ausschließlich wie gewünscht verwendet werden kann und somit »sicher« ist.

1.3 Der Aufbau Zu Anfang werden die gemeinsamen Grundlagen für das weitere Verständnis des Buchs gelegt. Es wird auf den historischen Entwicklungsprozess der Webanwendungen und des Webs eingegangen (siehe Kapitel 2, »Evolution des Webs«) und anschließend darauf, wie sich der Aspekt der Websicherheit in den letzten Jahren verändert hat. Danach wechseln wir durch das Einrichten der Testumgebung direkt in die Praxis (siehe Kapitel 3, »Einrichtung der Testumgebung«). Die Testumgebung dient dazu, Angriffe zu beschriebenen Angriffsvektoren selbst durchzuführen und zu Testzwecken mit den über die in Kapitel 14 beschriebenen Angriffstools zu verfügen.

Im anschließenden Kapitel beginnt die Auseinandersetzung mit verschiedenen Angriffsvektoren. Wir werden schauen, wie man sogenannten Sessions habhaft werden kann und welche Möglichkeiten zum Schutz bestehen (siehe Kapitel 4, »SessionAngriffe«). Das darauffolgende Kapitel widmet sich der Problematik des sogenannten Cross-Site-Scriptings. Wir werden verschiedene Techniken betrachten, um anschließend mögliche Schutzmaßnahmen zu evaluieren (siehe Kapitel 5, »Cross-SiteScripting (XSS)«). In Kapitel 6 wird es um nachgelagerte Datensysteme gehen. Wir werden feststellen, dass Angreifer bei unsicheren Applikationen mittels SQL-Injection Zugriff auf Datenbanken erlangen können und dass es weitere Speichermöglichkeiten gibt, bei denen Angreifer an Daten gelangen können. Natürlich betrachten wir auch, wie sich dieser unautorisierte Zugriff vermeiden lässt (siehe Kapitel 6, »Angriffe auf nachgelagerte Datenbanksysteme«). Authentifizierungssysteme gelten neben dem Session-Management als Kernstück vieler Webapplikationen, da darüber Zugriffe auf Funktionen und Accounts verwaltet werden. Wir werden schauen, wie man ihrer habhaft werden kann und wie es möglich ist, diese Prozesse sicher zu gestalten. Dazu werden wir unter anderem auf die Möglichkeiten des Passworthashings eingehen (siehe Kapitel 7, »Sicherheit von Authentifizierungsmechanismen«). In Kapitel 8 werden wir schauen, inwieweit die Einbindung von Dateien durch den Nutzer problematisch werden kann. Viele Webapplikationen sind heutzutage interaktiv und bieten neben Dateiuploads sogar die Möglichkeit, Dateien aus dem Internet einzubinden — dabei können viele Schwachstellen entstehen, die wir gemeinsam ausräumen wollen (siehe Kapitel 8, »File Inclusion«).

Wir werden sehen, dass einige Fehler in Applikationen auf ganz simplen Missverständnissen beim Geschäftsprozess beruhen. Diese logischen Fehler können mittlerweile so umfassend sein, dass wir ihre Gefahren sowie Möglichkeiten zur Abhilfe in einem eigenen Kapitel behandeln werden (siehe Kapitel 9, »Logische Fehler«). Informationen können Angreifern sehr weiterhelfen, sowohl bei bereits aus den vorherigen Kapiteln bekannten Angriffsvektoren als auch bei Angriffen mittels Phishing oder Social Hacking. Was genau das ist, und ab welchem Grad Informationen als sicherheitskritisch zu betrachten sind, sehen wir uns in Kapitel 10, »Informationspreisgabe«, an. Vor einigen Jahren wurde Cross-Site-Scripting in Fachkreisen belächelt — mittlerweile hat sich dort allerdings herumgesprochen, welche erheblichen Gefahren davon ausgehen. Heutzutage wird UIRedressing, vielen auch unter dem Begriff »Clickjacking« bekannt, schlichtweg unterschätzt. Viele Entwickler denken, dass auf dem Zielsystem keine Veränderungen vorgenommen werden, insoweit bestünde auch keine große Gefahr. Das ist allerdings ein folgenschwerer Irrtum, denn Clickjacking und Co. bedrohen die Nutzer direkt, teilweise sogar so perfekt, dass man als Seitenbetreiber kaum etwas davon mitbekommt. Es gibt jedoch Abhilfe, die wir uns gemeinsam anschauen möchten (siehe Kapitel 11, »UI-Redressing«). Am Ende des Hauptteils möchten wir zwei Dinge genauer betrachten, zum einen die Kombination von bereits bekannten Angriffen und zum anderen sonstige Angriffsvektoren, die nicht direkt Webapplikationen betreffen, letztlich aber auch die Sicherheit von Webangeboten gefährden können (siehe Kapitel 12, »Weitere Angriffsarten«). Anschließend möchten wir einen zusammenfassenden Blick zurückwerfen und einige »goldene Regeln« aufstellen. Wenn sich

jeder an diese halten würde, wäre schon viel in puncto Websicherheit gewonnen (siehe Kapitel 13, »Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche«). Es folgt eine langes Kapitel zu den Tools. Es gibt eine ganze Reihe von nützlichen Tools, die helfen können, Angriffe durchzuführen oder Lücken aufzuspüren. Wir wollen uns die bekanntesten Werkzeuge anschauen, um das zuvor erworbene Wissen anzuwenden und in unseren eigenen Systemen nach Lücken suchen zu können (siehe Kapitel 14, »Tools«). Bug-Bounty-Programme können eine organisatorische Maßnahme sein, um Sicherheitslücken in Webapplikationen zu schließen. Wie genau Bug-Bounty-Programme funktionieren und was dabei zu beachten ist, möchten wir in Kapitel 15 näher beleuchten (siehe Kapitel 15, »Bug-Bounty-Programme«). An einigen Stellen in diesem Buch werden Sie Methoden kennenlernen, die sich in der realen Welt kaum für das Gute einsetzen lassen. Welche Möglichkeiten es gibt, diese Fertigkeiten dennoch sinnvoll einzusetzen, werden wir in Kapitel 16 behandeln (siehe Kapitel 16, »Legal Webhacking durchführen«). Das Internet der Dinge breitet sich rasant aus, und Kontrollsysteme von Industrieanlangen sind längst vernetzt und lassen sich auch über das Web steuern. Wir möchten in Kapitel 17 über sogenanntes SCADA-Hacking sprechen und sehen, welche Angriffsmöglichkeiten sich daraus ergeben (siehe Kapitel 17, »SCADA-Hacking«). Sie werden feststellen, dass die meisten Kapitel nach dem gleichen Schema aufgebaut sind. Zunächst soll die Problematik der Lücke deutlich werden, häufig anhand von Codebeispielen, konkreten Fällen und einfachen Erklärungen, damit im Anschluss eine mögliche Abhilfe betrachtet werden kann.

1.4 Die Grenzen Es gibt keine absolute Sicherheit — aber immer Maßnahmen zur ihrer Erhöhung. Dieses Buch beschäftigt sich nicht oder kaum mit Lösungen im Rahmen der IT-Infrastruktur (etwa Firewalls) oder des Sicherheitsdesigns (Risikomanagement), sondern handelt primär vom Schreiben eines sicheren Codes, also dem Programmieren und der sicheren Konfiguration von Webservern. Es soll dabei helfen, ein Verständnis der Anatomien von Sicherheitslücken in Webanwendungen zu erlangen. Sie sollen dafür sensibilisiert werden, Ihren Code aufmerksamer zu implementieren und Konfigurationen bewusster vorzunehmen, um die Wahrscheinlichkeit einer angreifbaren Sicherheitslücke zu verringern. Einige Problematiken spezieller Programmiersprachen, wie C/C++, werden in diesem Buch nicht behandelt, da sie extrem komplex sind. Es ist unmöglich, sämtliche Angriffsvektoren und alle denkbaren Codevariationen in einem Buch abzubilden. Die Logik vieler Lücken ist jedoch ähnlich, und die Bandbreite der in diesem Buch beschriebenen Lücken so groß, dass Sie nach der Lektüre in der Lage sein sollten, durch kreatives Testen und den Transfer des Wissens weitere Lücken selbst zu identifizieren. Der mittlerweile recht umfangreiche Komplex der Websicherheit entwickelt sich dynamisch weiter. Täglich gibt es neue Tricks aus der dunklen Ecke des Internets und Whitepapers mit neuen Erkenntnissen aus diesem Bereich. Insofern empfiehlt es sich, dass Sie sich auch über das Buch hinaus informieren und sich auf dem aktuellen Stand halten.1

Ich werde an geeigneter Stelle Hinweise auf relevante Webprojekte oder weiterführende Literatur geben (siehe Kapitel »Literaturempfehlungen«). Weitere Quellen können Sie dem angehängten Quellenverzeichnis entnehmen. Eine letzte, in der Fachliteratur manchmal vernachlässigte Grenze möchte ich abschließend noch benennen: die der Akzeptanz seitens des Nutzers. Als Sicherheitsverantwortlicher oder Person mit Interesse an ITSicherheit neigt man zu Maßnahmen, die zwar unter dem Gesichtspunkt der Sicherheit hervorragend, für den Nutzer aber so lästig sind, dass dieser vom Einhalten dieser Regeln absieht oder die entsprechende Anwendung sogar nicht mehr nutzt. Letzteres wäre gerade im Bereich des Webs ein großes Übel, denn Webanwendungen sind dazu da, benutzt zu werden. Die Empfehlungen in diesem Buch sind fast immer auf größtmögliche Sicherheit angelegt. Deren Befolgung führt nicht zwangsläufig zu einer Optimierung im Sinne der Benutzbarkeit. Bei Veränderungen sollte somit (im Sinne eines ausgewogenen ChangeManagements) dafür gesorgt werden, die Akzeptanz der Nutzer zu gewährleisten. Die sicherste Webapplikation der Welt bringt nichts, wenn sie nahezu »unbenutzbar« wird. Es besteht beispielsweise oft ein Zielkonflikt zwischen Sicherheit und Benutzerfreundlichkeit/Bequemlichkeit (Usability). Es gibt eine Vielzahl weiterer Zielkonflikte, darunter an prominenter Stelle jener zwischen Sicherheit und Rentabilität. Generell gilt es, diese Zielkonflikte durch Kompromisse aufzulösen und abzuwägen, ob fragliche Ziele in einem noch vertretbaren Maße erreicht und sonstige vitale Interessen nicht erheblich missachtet werden.

1.5 Das (Kern-)Problem Gleich zu Anfang möchte ich auf ein mögliches Kernproblem zu sprechen kommen, wenn es um die Sicherheit von Webapplikationen geht: Viele Menschen (auch erfahrene Entwickler) denken, dass Applikationen etwas »falsch machen« oder die Sicherheit aufgrund der Applikation selbst nicht gegeben ist. Das ist jedoch weit gefehlt, denn Applikationen (und Computer generell) tun immer nur das, wozu sie angewiesen wurden. Sie folgen streng ihrem Ablauf und funktionieren, rein logisch betrachtet, wie sie es sollen. Nur wenn ein Fehler in der Verarbeitung einer Anweisung vorliegt, kommt es auch zu einem Fehler in der Applikation. Und Anweisungen kommen fast ausschließlich von dem Benutzer einer Anwendung. Wir werden in diesem Buch lernen, dass die meisten Fehler erst dann zu Sicherheitsrisiken werden, wenn Applikationen von den Entwicklern (während des Programmiervorgangs) nicht klar angewiesen wurden, wie sie zu funktionieren haben.

Bild 1.1: Ein typischer »Fehler«, entstanden durch die doppelte Bedeutung des Worts »Essen«.

Die hier abgebildete Google-Suche (von 2015) zeigt mustergültig, wie schnell es zwischen dem Nutzer und einer Anwendung zu Missverständnissen kommen kann. Es bleibt in der Suchformulierung unklar, ob wir »in Paderborn essen gehen« möchten oder von »Paderborn bis nach Essen gehen« möchten. Was in diesem Beispiel harmlos und ein Fehler ohne große Auswirkung ist, kann bei sensiblen Eingaben in komplexen Applikationen schnell zu einem Sicherheitsrisiko werden. Angreifer machen sich oftmals genau eine solche Systematik zunutze. Die Applikation kann dafür nichts, vielmehr sind es Entwickler und Programmierer, die nicht alle möglichen Fälle bedacht oder aufgefangen haben. Welche Folgen das genau haben kann und wie es uns gelingt, bestmöglichsten Schutz vor solchen

»Missverständnissen« zu erhalten, wollen wir gemeinsam in diesem Buch genauer untersuchen. Mittlerweile (2018) hat Google seiner Suchmaschine die Doppelbedeutung des Wortes »Essen« beigebracht. Einen Hintergrundartikel zu dem Thema finden Sie auf dem Blog zum Buch: https://hacking-im-web.de/blog-semantik-websicherheit.html 1

Grundsätzlich möchte ich bereits an dieser Stelle auf das »Open Web Application Security Project« (OWASP) aufmerksam machen, bei dem ich selbst Mitglied bin. Es ist eine Non-Profit-Organisation, die sich gezielt mit dem Thema Sicherheit von Anwendungen im WWW beschäftigt. Mehr dazu unter https://owasp.org/.

2 Evolution des Webs Bevor wir uns auf die Technik von Webapplikationen und deren Lücken konzentrieren, soll diese Einführung über den historischen Hintergrund erklären, wieso bis heute viele Webapplikationen unsicher sind und weshalb die (Un-)Sicherheit dieser Systeme von besonderer Bedeutung ist. Um das zu erreichen, werden die wichtigsten Entwicklungsstufen des Webs kurz umrissen.

2.1 Die Anfänge des Webs 1989 beschäftigte sich Tim Berners-Lee intensiv damit, Informationen und Ergebnisse von Forschungsprojekten zu »vernetzen«. Er entwickelte die Grundzüge des Webs, wie wir es heute kennen. In seinem Konzept baute er auf das bereits seit mehreren Jahren existierende Internet auf und entwickelte die Idee von abrufbaren Webseiten [4]. Wer sich mit Webseiten beschäftigt, weiß, dass es heute grundsätzlich zwei Typen von Webseiten gibt: zum einen die statischen und zum anderen die dynamischen Webseiten (meist Webapplikationen). Zu Beginn des Webs gab es ausschließlich statische Internetseiten, das sind jene, bei denen nur eine geringe Interaktion möglich ist. Einige von ihnen waren sogar reine Textdateien (.txt). Nach und nach wurden die meisten Webseiten allerdings mit einer abstrakten Auszeichnungssprache (HTML) strukturiert und enthalten oft verschiedene Elemente, die auf Abruf angezeigt werden können. Das Suchen, Eingeben und Verarbeiten von Daten ist auf diesen Webseiten allerdings nicht möglich, sie sind statisch.

Bild 2.1: Die Webseite des CERN-Instituts [5], eine der ersten Webseiten überhaupt — sie war statisch und verwies auf weitere Informationen über das WWW-Projekt.

Der Aufruf solcher Webseiten2 funktioniert bis heute nach folgendem Prinzip: Ein Benutzer navigiert zu einer bestimmten Stelle im Web, lädt ein Dokument herunter, der Inhalt wird interpretiert und dann dem Benutzer angezeigt. Die Übertragung von Inhalten erfolgte also zunächst überwiegend von Server zu Client. Schauen Sie einmal selbst auf der ersten Webseite überhaupt vorbei: http://info.cern.ch/hypertext/WWW/TheProject.html Mit der Zeit versuchte man, Möglichkeiten zu entwickeln, die Benutzerinteraktion zu steigern: Der Benutzer sollte dazu in der Lage sein, durch Eingabe von Daten die Website zu verändern oder Aktionen durchzuführen. Erstrebenswert erschien unter anderem das Verwenden eines Formulars oder die Suche nach gewissen Inhalten innerhalb einer Website. Was sich heute banal anhört, da wir es nahezu täglich nutzen, erschien damals bahnbrechend. Bereits 1991 wurde ein solches Vorgehen von einer Datenbankanwendung an der StanfordUniversität genutzt. Der erste Gebrauch dieser Applikation wurde auf deren Website umfassend dokumentiert [6]. Sie gilt bis heute als wohl erste Webapplikation, da sie in der Lage war, eine Eingabe des Nutzers serverseitig zu verarbeiten, Dokumente zu bearbeiten und diese wieder an den Nutzer auszugeben. Im Laufe der Jahre (etwa um 1993) war es erstmals möglich, auch völlig programmiersprachenunabhängig eine Eingabe des Endnutzers serverseitig zu verarbeiten. Dies wurde zur Erstellung von dynamischen Inhalten genutzt. Wenig später folgten weitere Entwicklungen. So wurde PHP (Hypertext PreProcessor) 1995 als Programmiersprache äußerst beliebt und zusammen mit dem neu geschaffenen Betriebssystem »Apache HTTP Server« zu einer Art Standard im Web. Bis heute ist der »Apache Server« laut Netcraft Webserver-Survery der meistgenutzte Webserver im Internet [7] und PHP eine der beliebtesten Programmiersprachen im Web3.

Mit diesen Technologien und Möglichkeiten nahm die Evolution des Webs Fahrt auf, und der Grundstein für moderne Webanwendungen war gelegt. Es schien nur noch eine Frage der Zeit, bis neben Forschungseinrichtungen auch Unternehmen die Technologien nutzen wollten, um Vorteile für ihre Geschäftsprozesse zu erzielen.

2.2 Die Boomphase des Webs Und genau so kam es: 1994 entwickelten zwei Studenten der Stanford-Universität die Idee, eine Art Übersicht über das Web zu schaffen, schließlich sah man sich einem gewaltigen Zuwachs an Webseiten und Informationen ausgesetzt. Wie sollte man den Überblick behalten und die Sachen finden, die man suchte? David Filo und Jerry Yang schufen mit Yahoo! eine der ersten bekannteren Webanwendungen. Sie wurde zur zentralen Anlaufstelle für viele neue und neugierige Nutzer, die das Web entdeckten. Ebenfalls 1994 gründeten die beiden Studenten ihr eigenes Unternehmen mit dem Namen »Jerry and David’s guide to the World Wide Web«, später wurde es in »Yahoo!« umbenannt. Das war offenbar der Moment in der Geschichte des Webs, an dem erstmals klar war, dass es nicht länger eine Randerscheinung von einigen Akademikern oder Wissen schaftlern bleiben würde, sondern dass immer mehr Innovationen in dem Bereich stattfinden würden. Viele große Unternehmen unterschätzten das Web jedoch zunächst und begannen erst recht spät, sich dafür zu interessieren. Dann wurden massenhaft Start-ups im Bereich der Informationsverarbeitung und Informationstechnologie in der Hoffnung gegründet, eine entscheidende Innovation im Bereich Web zu erzielen. Damit begann die Zeit der sogenannten »New Economy«, der Boomphase des Webs. Diese Ära endet mit einigen Erfolgsgeschichten, deren Ergebnis man heute noch sehen kann. Zu dieser Zeit entstanden Unternehmen wie Google, eBay, Amazon und Web.de, die heute erfolgreich am Markt etabliert sind (weitere siehe Tabelle unten). Neben den rein kommerziellen Erfolgen wurde auch technisch einiges Neues geschaffen. Viele der damaligen Technologien werden noch heute, allerdings in leicht abgewandelter Form, genutzt. Die wichtigsten Meilensteine sind in der nachfolgenden Tabelle dargestellt. Jahr Spezifikation

Servertechnologie Clienttechnologie Dienst

1994 HTTP-Cookie

1995 HTML 2.0 JavaScript Java 1.0

Apache HTTP

Netscape

Yahoo

Navigator 0.9

IMDb

Cold Fusion

Internet Explorer Amazon 1 eBay

PHP

JavaScript

Web.de

Jahr Spezifikation

Servertechnologie Clienttechnologie Dienst

1996 HTTP/1.0

Active Server Pages (ASP)

Frames

Macromedia Flash

HotMail Archive.org

CSS 1997 HTML 4.0

Netscape Composer GMX

JavaScript Standardisierung 1998 DOM

Internet Explorer NETFLIX 4 Zope

CSS 2

Google PayPal

Diese Phase war für das Web von besonderer Bedeutung, denn durch die enormen Investitionen und die Weiterentwicklung der Lösungen wurde das Web alltäglicher, und viele Standards wurden schnell weiterentwickelt. Immer mehr Menschen in den Industrienationen hatten einen Internetanschluss, zeitgleich wuchs die Anzahl der erreichbaren Applikationen im Web. Mitte der 1990er-Jahre bis zur Jahrtausendwende expandierte das Web sehr stark.

2.3 Webapplikationen heute Die Expansion setzte sich auch nach der Jahrtausendwende fort, und das Angebot im Web ist inzwischen unfassbar groß. Durch die neuen Technologien und einige findige Unternehmen erhielt auch der weniger technikversierte Nutzer die Möglichkeit, Inhalte im Web zu erstellen. Webapplikationen sind heute nicht mehr wegzudenken: Ob wir nur kurz online einen Blick auf das Wetter werfen, uns mit unseren Freunden über ein soziales Netzwerk schreiben, etwas zum Geburtstag unserer Freunde im Onlineshop kaufen, einem Onlinemeeting beitreten oder etwas in der Vertriebsdatenbank ändern — immer nutzen wir auch Webapplikationen. Durch das mobile Internet und Flatrates wurde die Nutzung des Webs im Consumerbereich weiter intensiviert. Webapplikationen sind weit verbreitete Anwendungen im Businessbereich (sowohl Business-to-Business als auch Business-to-Consumer) und werden zunehmend auch von Behörden (E-Government) genutzt. Nachfolgend sind typische Anwendungen und entsprechende Dienste des heutigen Webs aufgelistet:

● Suche nach Informationen (Nachrichten, Lexika, Wetter etc.) ● Websuche (Suchmaschinen: google.com / yahoo.com / bing.com)

● Soziales Vernetzen (facebook.com / twitter.com / myspace.com) ● E-Mailing (yahoo.com / web.de / gmail.com) ● Einkaufen (E-Commerce: amazon.com / zalando.de) ● Auktionen und Marktplätze (ebay.com) ● Onlinebanking (paypal.com) ● Handel mit Wertpapieren/Kryptowährungen (Bitcoin) ● Onlinewetten/Gewinnspiele/Onlinespiele (Browserspiele) ● Blogs (wordpress.com, blogger.com) ● Medien (spiegel.de / zeit.de / youtube.com) Durch das Aufkommen von Smartphones wurde ein zusätzlicher Markt geschaffen. Viele Apps auf Smartphones sind mit Schnittstellen zum Web ausgestattet.4 Es gibt für sehr viele Systeme mittlerweile Schnittstellen im Web, so sind etwa ERPSysteme über Webapplikationen erreichbar. Auch die Konfiguration von Hardware wird über Webanwendungen durchgeführt, und selbst im Bereich der Industriemaschinensteuerung (ICS) oder der Auswertung und Kontrolle (SCADA) gibt es die Tendenz, Steuerungssysteme über Webapplikationen bedienbar zu machen. Der Vorteil von Webapplikationen ist schlichtweg, dass diese auf nahezu jedem Endgerät lauffähig sind und kaum Ressourcen verbrauchen. Alles in allem ist in der ersten Dekade des 21. Jahrhunderts der Siegeszug des Webs und der von Webapplikationen unübersehbar, es ist der wohl wichtigste, zumindest aber der meistgenutzte, Dienst im Internet geworden. Das Web ist eine Technologie, die das Leben mehrerer Milliarden von Menschen täglich stark beeinflusst und von ihnen vielfältig genutzt wird. Zudem bauen Unternehmen ihr komplettes Geschäftsmodell darauf auf, und nahezu jedes Unternehmen nutzt Webapplikationen zur Unterstützung des laufenden Betriebs oder der Repräsentation im Web — aus diesem Grund ist die Sicherheit solcher Systeme sehr wichtig.

2.4 Webapplikationen in der Zukunft

Da es weiterhin einen Zuwachs an Vernetzung zwischen verschiedenen Systemen geben wird, ist zu vermuten, dass das Web ebenfalls in diese Bereiche integriert wird. Mittlerweile wurde mit dem »Internet der Dinge« eine ähnliche Goldgräberstimmung heraufbeschworen, wie sie einst zu den Boomzeiten des Webs herrschte — viele Hersteller wollen ihre Geräte »smart« machen, dazu nutzen sie meist auch Webapplika tionen oder Apps. Es ist sehr wahrscheinlich, dass die Auswertung und vor allem die Darstellung von großen Datenmengen (»Big Data«) durch Webapplikationen erfolgen wird, da diese einfach zu bedienen und nahezu von jedem Endgerät aus zugänglich sind. Im Bereich des E-Government ist damit zu rechnen, dass langfristig eine vermehrte Authentifizierung über das Internet stattfinden wird, Webapplikationen würden eine benutzerfreundliche und plattformunabhängige Möglichkeit darstellen, diese Idee umzusetzen. Die Relevanz des Webs wird also angesichts dieser kurz genannten Beispiele in keinem Fall abnehmen, es ist eher stark davon auszugehen, dass es mit anderen Technologien zusammen seine Relevanz weiter ausbauen wird.

2.5 Entwicklung der Websicherheit Websicherheit war fast immer ein eher beiläufiges, ja offenbar für viele unnötiges Thema. Zu Beginn des Webs spielte es gar keine Rolle, denn bei statischen Webseiten gibt es kaum Möglichkeiten, auf Anwendungsebene Angriffe durchzuführen. Es war schlicht nicht möglich, als Client komplexe Anweisungen an den Webserver oder an Subsysteme zu schicken, wenn es sich um eine statische Seite (etwa HTMLDokumente oder TXT-Dateien) handelte. Ein weiterer Faktor — und wohl ein bedeutender Grund dafür, dass man sich nicht besonders stark um die Sicherheit des Webs kümmerte — war, dass man sich vertraute; die Nutzer der ersten Stunde waren allesamt Forscher und kannten sich sehr gut. Mehr als die »Vernetzung« von Wissen stellte das Web zunächst nicht dar; es war eine Art wissenschaftlicher Versuch, bei dem damals nicht abzusehen war, was dabei herauskommen würde. Nach dem Aufkommen der ersten größeren Webapplikationen und der Kommerzialisierung Mitte der 1990er-Jahre wurde dann allerdings nach und nach deutlich, dass Sicherheit doch ein extrem wichtiges Thema sein muss — lange Zeit hatte man sich eher darauf konzentriert, auf Netzwerk- bzw. Infrastrukturebene Sicherheit zu schaffen. Viele Unternehmen setzen bis heute teure Enterprise-Firewalls oder komplexe Netzwerk-Firewalls ein, führen die neuesten Softwarepatches durch, verschlüsseln ihre Kommunikation und führen immer wieder Penetration-Tests durch. Sie denken, dass sie sicher vor Angriffen seien, schließlich haben sie eine moderne Firewall, viele Schutzmechanismen und im besten Fall weitreichende Sicherheitsstandards. Grundsätzlich bietet diese Art von Maßnahmen auch einen gewissen Schutz, etwa vor sogenannten »Distributed Denial of Service«-Attacken (DDOS, massenhaften Anfragen, die eine Dienstüberforderung verursachen), unberechtigten

Zugriffen und Man-in-the-Middle-Angriffen (MITM-Angriffen), trotzdem können diese Schutzwälle und Maßnahmen allein niemals die Sicherheit eines Systems mit Webapplikationen garantieren, da sie auf der Transportebene, nicht aber auf der Applikationsebene ansetzen. Meist fungieren zum Beispiel die Firewalls nur als eine Art »Türsteher«, durch den gewisse Zugriffe auf Netzwerkdienste zugelassen oder eben unterbunden werden. Diese konventionellen Schutzmaßnahmen stoßen aber bei der Sicherheit von Webanwendungen an ihre Grenzen, da sie oft ausschließlich auf Netzwerkprotokollebene analysieren, aber nicht beobachten, was nach dem Durchkommen tatsächlich passiert und welche möglicherweise schädlichen Zeichen ein Parameter beinhaltet. Da es immer wieder zu Zwischenfällen und Hacks größeren Ausmaßes kam, fand Anfang der 2000er ein Umdenken statt, das bis heute anhält. Man erkannte, dass gerade im Bereich des Webs eine erhebliche Gefahr bestand, denn: Die Hürde für Angreifer ist oft gering5 — der Schaden kann jedoch enorm sein.6 Es stellt sich also folgende Frage: Wie schafft man es, Webanwendungen sicher zu machen? Die Antwort fällt uns nicht leicht, denn das Web war in der Entwicklung schlicht schneller als seine Macher. Dass sich aus dieser Idee einmal so viel entwickeln würde, war nicht absehbar, deshalb gab es kaum verbindliche Sicherheitsstandards, sondern lediglich RFC (Requests For Comment) oder BCP (Best Current Practice). Nach und nach etablierten sich jedoch auch verbindlichere Internetstandards (STD). 2001 wurde vor allem durch die Gründung des »Open Web Application Security Project« (OWASP) erstmals vermehrt über das Thema Sicherheit von Webapplikationen diskutiert. Bis heute stellt diese Organisation eine entscheidende Säule im Bereich der Websicherheit dar. So werden beispielsweise die sogenannten »OWASP Top 10« veröffentlicht, bei denen es sich um die Darstellung der zehn größten Bedrohungen bzw. Sicherheitslücken von Webapplikationen handelt. [8] Erstaunlich ist, dass es bis heute zu vielen Hacks von Webapplikationen über bereits bekannte Angriffsvektoren kommt, obwohl das Thema und entsprechende Problematiken mittlerweile seit weit über zehn Jahren diskutiert werden. Daran wird jedoch noch einmal deutlich, dass es zum einen kein Allheilmittel gibt und zum anderen offenbar noch keine hinreichende Sensibilisierung aller Entwickler in dem Bereich stattgefunden hat. Oftmals scheint der Fokus beim Lehren einer Programmiersprache nicht in erster Linie auf Sicherheit, sondern auf Funktionsfähigkeit zu liegen. Eine weitere Entwicklung ist, dass Applikationen, die man noch vor fünf Jahren für sicher hielt, heute möglicherweise unsicher geworden sind, weil neue Angriffsvektoren entdeckt wurden. Es bedarf also wachsamer und informierter Programmierer, um eine fortdauernde Sicherheit zu gewährleisten, da das technische Umfeld sehr dynamisch ist.

Zwischenzeitlich glaubte man, das Problem von Lücken in Webapplikationen weitgehend in den Griff zu bekommen, indem man sogenannte Web-Application-Firewalls (WAFs) entwickelte. Diese Systeme sollten ähnlich wie Firewalls arbeiten und zum Beispiel auffällige Anfragen blockieren, indem die Inhalte genauer betrachtet und nicht bloß Netzwerkpakete dahingehend kontrolliert wurden, ob der Dienst oder das Protokoll zulässig ist. Tatsächlich führte das aber nicht wirklich zum Erfolg, denn zum einen ist die Implementierung eines solchen Systems mit sehr viel Aufwand verbunden, weil es praktisch vor den Webserver geschaltet werden muss und dadurch die Komplexität des Systems erhöht. Und zum anderen gab es immer wieder Zwischenfälle, bei denen die Filterregeln dieser Firewalls einfach umgangen werden konnten. Diese WAFs dürften also nur als »Auffangnetz« infrage kommen und halten möglicherweise unerfahrene Angreifer auf. Es ist allerdings mehr Verlass auf wirklich sicheren Code. Die neuesten Tendenzen im Bereich der Websicherheit bilden sogenannte Bug-BountyProgramme, bei denen Sicherheitsexperten entlohnt werden, wenn sie Unternehmen eine Lücke in ihrer Applikation verantwortlich melden. Damit wollen Unternehmen dem florierenden Schwarzmarkt im Bereich der Lücken Einhalt gebieten und ihre Dienste sicherer machen, um einen Hack und einen damit verbundenen Imageschaden zu vermeiden. Unternehmen, die ein solches System im Einsatz haben, etwa Google [9] und Facebook [10], blieben bis jetzt sogar weitgehend unversehrt. Vielleicht ist diese Art der Websicherheit also auch ein Modell für die Zukunft. Insgesamt ist das Web besonders aufgrund der Durchdringung vieler Lebensbereiche ein bedeutender Teil des Alltags von Privatpersonen und Unternehmen geworden. Diesen vor potenziellen Angreifern zu schützen, erweist sich als zwingend notwendig. Der Sicherheit von Webapplikationen sollte also eine sehr hohe Relevanz zukommen, insbesondere in Unternehmen, in denen die eigentliche Wertschöpfung durch Produkte im Web erreicht oder entscheidend unterstützt wird. 2

Das Internet selbst ist eine Plattform für Dienste, etwa das Web. Im Web gibt es Seiten, deshalb der Begriff »Webseiten«. »Internetseiten« ist streng genommen ein Wort der Umgangssprache und wird deshalb in diesem Fachbuch vermieden.

3

Das ist der Hauptgrund, weshalb unser Setup für die Testumgebung ebenfalls auf diesen Technologien basiert (dazu später mehr).

4

Die Sicherheit von mobilen Apps ist ein sehr wichtiges, jedoch eigenes Thema, das in diesem Buch nicht vertiefend behandelt wird. Viele der später aufgezeigten Lücken sind aber in ähnlicher Form auch im Bereich der App-Sicherheit möglich.

5

Oftmals ist nicht einmal das Umgehen einer komplexen Firewall oder die Kenntnis der im Hintergrund arbeitenden ITInfrastruktur vonnöten, ein simpler Webbrowser mit einigen Erweiterungen genügt, um Schaden anzurichten, wie wir später sehen werden.

6

Überlegen Sie bitte einmal selbst, was der Diebstahl Ihrer Kundendaten oder die Verunstaltung der Webseite für Ihr Unternehmen bedeuten würde.

3 Einrichtung der Testumgebung Wie im Eingangskapitel erwähnt, soll es möglich sein, die in diesem Buch beschriebenen Angriffe praktisch nachzuvollziehen, um die Sicherheit der eigenen Webapplikation zu testen. Dazu ist die Einrichtung einer Testumgebung auf Basis von Linux (im Idealfall »Kali Linux«) notwendig. Im folgenden Kapitel lernen Sie, wie diese erstellt wird.

3.1 Kali Linux herunterladen und installieren Kali ist ein aus BackTrack hervorgegangenes Debian-Derivat, das sich mittlerweile in der IT-Security-Szene als das wohl beliebteste Pentesting-Betriebssystem etabliert hat. Es enthält viele PentestingTools, die übersichtlich in verschiedene Kategorien aufgeteilt sind. Kali Linux wird durch die Firma »Offensive Security« betreut. Auf einer eigenen Webseite zum Betriebssystem finden Sie eine Vielzahl an Möglichkeiten zum Download: https://www.kali.org/downloads An dieser Stelle müssen Sie selbst entscheiden, ob Sie Kali Linux auf einem gesonderten Rechner installieren möchten oder ob Ihnen eine virtualisierte Umgebung (mittels VMware oder VirtualBox) genügt. Die Installation sollte keine große Herausforderung

darstellen, da auf der Webseite von Kali umfassende Informationen zu verschiedenen Installationstypen hinterlegt sind7: https://docs.kali.org/category/installation Nachdem die Installation durchgeführt wurde, können Sie sich mit dem während der Installation festgelegten Nutzernamen und dem entsprechenden Kennwort anmelden. Haben Sie während der Installation weder Nutzernamen noch Kennwort angeben müssen, so handelt es sich vermutlich um vorgefertigte virtuelle Maschinen. Die Logindaten dafür sind: Nutzername: root Passwort: toor

Nach dem erfolgreichen Login sollten Sie die folgende DesktopOberfläche sehen.

Bild 3.1: Die Oberfläche von Kali Linux nach erfolgreicher Installation und Login.

3.2 Betriebssystem aktualisieren und Nutzer anlegen Nachdem die Installation von Kali Linux erfolgreich war, sollten zunächst das Betriebssystem und die entsprechende Software aktualisiert werden. Dazu öffnen wir den Terminal (in der Seitenleiste das zweite Symbol) und geben folgende Kommandos ein (Bestätigung der Befehle mit Enter): sudo apt-get install upgrade sudo apt-get install update

Je nach Internetanbindung kann die Aktualisierung einen Moment in Anspruch nehmen. Sollte an dieser Stelle die Eingabe auf Grund falscher Tastatureinstellungen (US-Layout) nicht direkt gelingen, geben Sie folgenden Befehl ein und setzen ihn mit Enter ab: setxkbmap de

Durch den Befehl wird das DE-Tastaturlayout aktiviert. Sind die Updates erfolgt und das korrekte Tastaturlayout festgelegt, so sollte anschlie ßend ein neuer Nutzer angelegt werden8. Die Anlage eines neuen Nutzers kann nach Öffnung des Terminals durch folgende Befehle stattfinden: useradd -m hacker

Dadurch wird ein neuer Nutzer mit dem Namen »hacker« und gleichzeitig ein Benutzerverzeichnis für den Nutzer angelegt.

Durch die Eingabe von folgendem Befehl lässt sich das Passwort für den Nutzer festlegen: passwd hacker

Das Passwort muss anschließend zweimal eingegeben und mit Enter bestätigt werden. Durch die Ausgabe »passwd: password update successfully« wissen wir, dass die Vergabe des neuen Passwortes erfolgreich war. Um mit dem neu angelegten Account beispielsweise Softwareinstallationen vornehmen zu können, empfiehlt es sich, den Account in die Gruppe »sudo« aufzunehmen. Um dies zu tun, können wir folgenden Befehl nutzen: usermod -a -G sudo hacker

Um nun noch »bash« als Standard-Shell im Terminal festzulegen, sollten wir abschließend noch folgenden Befehl ausführen: chsh -s /bin/bash hacker

Damit sind alle notwendigen Schritte abgeschlossen.

3.3 Chromium installieren Wie Sie vielleicht schon in der Seitenleiste von Kali Linux erkannt haben, verfügt das Betriebssystem im Standard über den Mozilla Firefox als Webbrowser. Wir möchten für spätere Zwecke an dieser Stelle schon einmal einen zweiten Browser (Chromium) installieren und geben dafür folgenden Befehl in das Terminal ein: sudo apt-get install chromium

Während der Installation kann es sein, dass Sie gebeten werden, mit »Y« oder »J« die Freigabe von Festplattenspeicher zu erlauben. Der Download kann je nach Internetverbindung etwas Zeit in Anspruch nehmen.

3.4 DVWA installieren und konfigurieren DVWA (Damn Vulnerable Web Application) ist, wie der Name bereits erraten lässt, eine »Verdammt verwundbare Webapplikation«. Die unsichere Anwendung wurde zu dem Zweck entwickelt, Hackern/Sicherheitsforschern (oder solchen, die es werden möchten) zu ermöglichen, in einer legalen Umgebung Erfahrungen zu sammeln. Wir möchten die DVWA auf unserem System installieren und lokal als Webservice erreichbar machen. DVWA steht unter der GNU Public License und ist eine PHP/MySQL-Webapplikation, wie sie vielfach auch im Web zu finden ist9. Auf den Webseiten www.dvwa.co.uk https://qithub.com/ethicalhack3r/DVWA finden sich Informationen und Hinweise zu dem Projekt.

und weitere

Vorab ein wichtiger Hinweis: Da diese Webapplikation Sicherheitslücken aufweist, sollte sie niemals auf einem öffentlichen Webserver betrieben werden, sondern ausschließlich in einem lokalen Netzwerk!

Um die Installation vorzunehmen, wechseln wir zunächst in den Ordner des Webservers (in unserem Fall Apache2), dazu nutzen wir folgenden Befehl:

cd /var/www/html

Anschließend laden wir mittels wget die entsprechenden Ressourcen herunter und entpacken sie mit unzip: wget https://github.com/ethicalhack3r/DVWA/archive/master.zip && unzip master.zip

Nach Ausführung des Befehls befindet sich ein Ordner »DVWAmaster« im Verzeichnis (kann durch »ls« geprüft werden). Durch folgenden Befehl kann der Inhalt aus dem Verzeichnis in einen dafür vorgesehenen Ordner mit der Bezeichnung »dvwa« verschoben werden: mv DVWA-master//var/www/html/dvwa

Wurden die Dateien verschoben, müssen dem Ordner noch die notwendigen Zugriffsrechte zugewiesen werden: chmod -R 777 dvwa

Soweit erst einmal zu der Ablage des Quellcodes von DVWA. Als nächstes sollte geprüft werden, ob PHP korrekt installiert ist. Dazu kann man folgenden Befehl verwenden: php -v

Dadurch wird angezeigt, ob PHP installiert ist, und welche Version davon vorliegt.

Bild 3.2: Anzeige der PHP-Version

In diesem Fall liegt PHP in der Version 7.2 vor und kann offensichtlich ohne Probleme durch einen Webserver verwendet werden. Liegt auf Ihrem Linux-System kein PHP oder Apache vor, so kann beispielsweise folgendes Tutorial genutzt werden: https://howtoforge.com/tutorial/install-apache-with-php-and-mysqlon-ubuntu-16-04-lamp/ Für Windows gibt es auch einige Tutorials zur Installation von DVWA, bspw. mittels XAMPP: http://www.effecthackmg.com/2015/12/setup-dvwa-usmg-xamppwindows.html Um die Webapplikation lauffähig zu machen, ist es notwendig, eine Datenbank zu nutzen. Dazu starten wir zunächst den MySQLService: service mysql start

Anschließend können wir noch die Datenbank mit folgendem Befehl konfigurieren: mysql -u root -p

Nun wird nach einem Passwort gefragt. Dazu können wir das bekannte Root-Passwort (»toor«) oder unser selbst konfiguriertes Kennwort nutzen. Es öffnet sich die Eingabemaske des lokalen Datenbankservers.

Bild 3.3: Eingabekonsole der Datenbank

In der Eingabekonsole der Datenbank geben wir jetzt folgende Befehle ein10: CREATE USER 'dvwa_user'@'127.0.0.1' IDENTIFIED BY 'securepw';

Dadurch wird der Datenbanknutzer »dvwa_user« mit dem Passwort »securepw« angelegt. Anschließend erstellen wir noch eine neue Datenbank mit dem Namen »dvwa«, mit diesem Befehl: CREATE DATABASE dvwa;

Dem neu angelegten Nutzer »dvwa_user« geben wir Zugriff auf die Datenbank »dvwa«, mit folgendem Befehl: GRANT ALL ON dvwa.* TO 'dvwa_user'@'127.0.0.1';

Die Änderungen werden direkt aktiviert durch die Eingabe des folgenden Befehls in die Datenbankkonsole: FLUSH PRIVILEGES;

Diese verlassen wir, indem wir den Exit-Befehl eingeben: exit

Wir haben damit erfolgreich einen neuen Nutzer (»dvwa_user«) und eine neue Datenbank (»dvwa«) erstellt und die entsprechenden Berechtigungen verliehen. Um nun der Webapplikation die Nutzung der Datenbank zu ermöglichen, müssen wir eine Datei mit dem Namen »config.inc.php« erstellen. Dazu wechseln wir in den Konfigurationsordner von DVWA: cd /var/www/html/dvwa/config/

Sofern DVWA nicht zuvor schon einmal genutzt wurde, sollte sich dort nur eine Datei mit dem Namen »config.inc.php.dist« befinden. Dabei handelt es sich um eine beispielhafte Konfigurationsdatei. Diese kann mit folgendem Befehl kopiert werden: cp config.inc.php.dist config.inc.php

Die Bearbeitung der neu erstellten Konfigurationsdatei erfolgt durch die Eingabe von: gedit /var/www/html/dvwa/config/config.inc.php

Nach Abschicken des Befehls öffnet sich der Texteditor »gedit«11. Dort müssen nun in Zeile 34-37 die zuvor angelegten Informationen des SQL-Servers hinterlegt werden. In unserem Fall sollte das Ganze anschließend so aussehen:

Bild 3.4: Konfigurationsdatei von DVWA

Ist sichergestellt, dass wir PHP nutzen können und die Datenbank korrekt konfiguriert haben, starten wir in einem nächsten Schritt den Apache2-Webserver. service apache2 start

Dadurch wird im Hintergrund ein Prozess des Webservers gestartet. Dieser sollte nun über folgende URL erreichbar sein: http://127.0.01/dvwa/ Auf der Weboberfläche von DVWA müssen wir uns nun entweder authentifizieren, indem wir folgende Logindaten nutzen: Nutzername: admin Passwort: password

Oder wir werden automatisch auf die Konfigurationsseite von DVWA weitergeleitet. Dort können wir sehen, welche Einstellungen bereits korrekt getroffen worden sind (grün) und bei welchen wir noch etwas nachhelfen sollten (rot).

Bild 3.5: Konfigurationsseite von DVWA

Wie wir dem unteren Bereich der Seite entnehmen können, sollen folgende Werte gesetzt werden: allow_url_fopen = On allow_url_include = On

Bei diesen Werten handelt es sich um globale Variablen in PHP. Um diese zu ändern, müssen wir die Datei »php.ini« anpassen. Wir können dazu folgenden Befehl nutzen: gedit /etc/php/7.0/apache2/php.ini

Um die Werte selbst zu finden, können wir »Strg« + »F« drücken. Neben den angeführten Parametern setzen wir auch »display_errors« durchgängig auf »On« bzw. »True«. Wurden die Konfigurationen vorgenommen, so kann die Datei »php.ini« mit einem Klick auf »Save« gespeichert werden. Anschließend ist, wie auf der Konfigurationsseite von DVWA beschrieben, ein Neustart von Apache2 notwendig: service apache2 restart

Anschließend können wir die Konfigurationswebseite im Browser neu laden und stellen fest, dass bis auf »PHP module gd: Missing« und »reCAPTCHA key: Missing« keine roten Warnungen mehr ausgegeben werden - das ist der erwünschte Zustand. Mit dem Klick auf den Button »Create / Reset Database« wird nun die Datenbank mit Inhalten gefüllt. War der Vorgang erfolgreich, so erscheinen einige Erfolgsmeldungen. Am Ende steht »Setup successful!«.

Bild 3.6: Erfolgsmeldungen nach dem Erstellen der Datenbank Hinweis: Bei Problemen gilt es, die SQL-Daten aus der Konfigurationsdatei erneut zu prüfen. Zudem sollte der Restart der Services mysql und apache2 eingeleitet werden.

Die Installation und Konfiguration unserer Testumgebung haben wir damit erfolgreich abgeschlossen. Nun können wir uns anmelden (admin/password) und sehen in der Seitenleiste einige Links, welche sehr an einige Kapitelnamen aus dem Buch erinnern: Let’s hack! An dieser Stelle sei schon mal auf zwei wichtige Funktionalitäten von DVWA hingewiesen. Sicherheitslevel DVWA bietet die Möglichkeit, ein Sicherheitslevel für die Applikation festzulegen. Diese Einstellung lässt sich im Seitenmenü unter »DVWA Security« vornehmen und bietet die folgenden Auswahlmöglichkeiten an:

● Low (niedrig)

● Medium (mittel) ● High (hoch) ● Impossible (unmöglich) In der Standardeinstellung ist dieser Wert auf »Impossible« gesetzt. Um Angriffe vornehmen zu können, muss der Wert verändert werden, mit »Low« sind alle Beispiele aus diesem Buch umsetzbar. Sofern Sie schon etwas fortgeschritten sind, können Sie auch andere Sicherheitslevel auswählen und ihr Können unter Beweis stellen. Reset von DVWA Nach Angriffen auf unsere Testumgebung kann es sein, dass sie korrupte Daten enthält oder nicht mehr alle Funktionen wie gewohnt zur Verfügung stehen. Um dem Einhalt zu gebieten, verfügt DVWA über eine Art »Reset-Funktion«, diese lässt sich unter »Setup« finden und ist mit »Create/Reset Database« beschrieben. 7

Sollte es dennoch Informationsbedarf zu Kali Linux geben, empfehle ich Ihnen das Buch »Hacking

mit

Kali«

aus

dem

Franzis

Verlag

von

Andreas

Weyert

(siehe

»Literaturempfehlungen«). 8

Grundsätzlich sollte man ein System immer nach dem »Least Privilege Prinzip« administrieren. Der »root«-Nutzer unter Linux ist der mächtigste Nutzer.

9

PHP ist nach wie vor die meistverbreitete Sprache im WWW. Wir nutzen in diesem Fall PHP 7 mit Maria DB, da dies auf dem neuesten Kali Linux als Standard vorliegt.

10

Bei den Befehlen zu SQL ist stets darauf zu achten, dass die SQL-Statements mit Semikolon (;) enden.

11

Statt »gedit« kann natürlich auch auf Texteditoren zurückgegriffen werden, welche in der Shell nutzbar sind, bspw. »vim« oder »vi«.

4 Session-Angriffe Die allermeisten werden schon von HTTP (Hypertext Transfer Protocol), dem zustandslosen Protokoll des Web gehört haben. Die Zustandslosigkeit bewirkt, dass es nicht möglich ist, verschiedene Anfragen eines Nutzers als zusammengehörig zu erkennen. Um einen Zusammenhang zwischen einzelnen Anfragen zu ermöglichen, lassen sich beispielsweise Cookies einsetzen. IP-Adressen allein sind in puncto Identifizierung nicht zuverlässig genug, da hinter einer IP-Adresse mehrere Clients stehen können (etwa bei Proxys oder VPNs). Session-Management bietet die Möglichkeit, einzelne Anfragen zu verbinden, und ist deshalb gewissermaßen das Herzstück einer modernen Webanwendung mit Benutzerfunktionen. Wenn bei diesem fundamentalen Mechanismus eine fehlerhafte Implementierung vorliegt, hat das in jedem Fall Auswirkungen auf die gesamte Sicherheit der Anwendung. Oftmals werden gerade über diese Komponente Identifikation und Autorisierung gegenüber der Anwendung vorgenommen. Daher sind Schwächen in diesem Bereich unbedingt zu eliminieren. Bevor wir auf tatsächliche Angriffsmöglichkeiten zu sprechen kommen, schauen wir uns zunächst die technische Umsetzung genauer an: Mittels einer sogenannten Session ist es möglich, Anfragen eindeutig einem Nutzer zuzuordnen. Erst dadurch werden dynamische und interaktive Webapplikationen nutzbar, indem etwa nutzerbezogener Inhalt angezeigt werden kann. Bei einer Session handelt es sich um eine Sitzung. Durch die Session-ID (Sitzungs-ID, SID), die beim Start einer Sitzung zufällig erzeugt wird und eindeutig ist, kann man Anfragen einem Nutzer zuordnen. Bei jeder Anfrage, bei der bereits eine Authentifizierung mittels Log-in stattgefunden hat, wird an die Applikation die Session-ID zur Prüfung (meist in einem HTTP-Headerfeld)

übergeben. Damit gibt sich der Nutzer der Applikation gegenüber zu erkennen, und vorangegangene Anfragen können mit der aktuellen in Verbindung gebracht werden. Das ist äußerst nützlich, etwa bei dem Ablegen eines Artikels im Warenkorb oder um sich die Daten eines Nutzers zu merken und sie im Nutzerbezug zu verarbeiten. Außerdem ist es Anwendern dadurch möglich, die Webapplikation über längere Zeit zu verwenden, ohne sich bei jeder neuen Anfrage wieder erst identifizieren zu müssen. Nahezu jedes bekannte Framework verfügt über einen Mechanismus zum Session-Management. Es ergibt Sinn, diese Frameworks zu verwenden und nicht einen selbst erstellten, möglicherweise unsicheren Mechanismus. Die »Session-ID-Namen« der bekanntesten Webframeworks sind nachfolgend aufgelistet: Webapplikation-Framework

Session-ID-Name

PHP

PHPSESSID

Microsoft IIS Server

ASPSESSIONID

Cold Fusion

CFID/CFTOKEN

J2EE (Java)

JSESSIONID

ASP.NET

ASP.NET_SessionId

Sessions werden mit einer Laufzeit versehen, enden also nach einer gewissen Zeit und fungieren somit gewissermaßen als Kurzzeitpasswort. Ihre Laufzeit sollte so lang sein, wie die Sitzung aufrechterhalten werden soll. Das »Abmelden« oder ein »Logout« in einer Webapplikation durch den Nutzer bedeutet, dass die Session-ID ungültig wird. Sie kann aber von der Applikation als abgelaufen gekennzeichnet werden (automatisches Log-out), etwa wenn der Benutzer sehr lange keine Eingabe oder Interaktion mehr durchgeführt hat (z.B. beim Online Banking). Es gibt verschiedene Möglichkeiten, die Session-ID zwischen Server und Client zu übertragen. Die bekanntesten sind nachfolgend aufgeführt:

● Die gängigste Vorgehensweise ist, ein Cookie (Textwert) zu setzen, mit dem sich der Client fortan identifiziert (Übertragung durch HTTPHeaderfelder).

● Eine weitere Möglichkeit ist, in Formularen ein verstecktes Feld zu nutzen und mit dem HTML-Tag (Inhalte in diesem Tag werden nicht angezeigt) und der POST-Methode die Session-ID zu übertragen.

●

Zudem kann die Session-ID als URL-Parameter mit der GET-Methode übertragen werden (davon ist allerdings abzuraten).

Zur Übermittlung zwischen Client und Server kann stets das HTTP-Protokoll genutzt werden. Eine Verschlüsselung ist möglich und ausdrücklich zu empfehlen. Die Session-ID wird zu Beginn einer Session serverseitig festgelegt (HTTPHeaderfeld: Set-Cookie) und bei jeder neuen Anfrage vom Client mitgesendet (HTTP-Headerfeld: Cookie), damit dieser sich gegenüber der Webapplikation als bereits bekannt ausgeben kann. Sendet der Client keine Session-ID, falls beispielsweise der Browser diese Funktion nicht unterstützt, so ist keine anhaltende Session möglich. Wie deutlich wird, vertraut der gesamte Mechanismus darauf, dass der Client stets die eigene Session-ID zurücksendet, jene, die er zu Beginn seiner Sitzung erhalten hat. Solange diese Regel eingehalten wird und zudem sichergestellt ist, dass nicht zwei Nutzer die gleiche Session-ID haben, funktioniert alles wie gewünscht. Wir möchten uns aber einmal damit beschäftigen, was passiert, wenn sich einige Clients nicht an die Regeln halten, also herausfinden, wie es möglich ist, des Systems des SessionManagements habhaft zu werden. Dazu betrachten wir nachfolgend die Angriffsvektoren »Man-in-the-Middle-Angriff«, »Cookie-Replay-Angriff«, »Session-Hijacking« und »Session-Fixation«. Anschließend schauen wir uns die Empfehlungen und Abhilfen aus Entwicklersicht an.

4.1 Man-in-the-Middle-Angriff

Ein ein sogenannter »Man-in-the-Middle-Angriff« (MitM-Angriff) ermöglicht das Auslesen der Session-ID, da die Kommunikat ion (falls unverschlüsselt — HTTP) abgehört werden kann. Das Vorgehen ist allerdings mit gewissem Aufwand verbunden, da der Angreifer Zugang zu dem Netzwerk haben muss, um mithilfe eines Packet-Sniffers (zum Beispiel »Wireshark«, siehe »Tools«) die entsprechenden Informationen mitzuschneiden. Der Angreifer belauscht anschließend den Verkehr zwischen dem Client und dem Webserver. In öffentlichen Netzen, wie beispielsweise WLANs, ist ein solches Szenario durchaus denkbar.

Bild 4.1: Skizzie rung eines Man-in-the-Middle-Angriffs.

Um einmal selbst nachzuahmen, wie ein Man-in-the-Middle-Angriff aussehen kann, wechseln wir in unsere Testumgebung (Kali Linux) und starten das Terminal. Anschließend geben wir folgenden Befehl ein und bestätigen ihn mit Enter: wi reshark

Dadurch startet der Packet-Sniffer »Wireshark«12. Innerhalb von Wireshark kann man sämtliche Netzwerkinterfaces (den Loopback, LAN-Verbindungen,

WLAN-Verbindungen) auswählen und den Netzwerkverkehr mitschneiden. Hinweis: Wireshark kann bei generellen IT-Problemen weiterhelfen, etwa indem man untersucht, ob der Verkehr wie geplant versendet wird.

Sie können an dieser Stelle verschiedene Aktionen vornehmen, um zu erkennen, welche Problematik sich durch Man-in-the-Middle-Angriffe ergibt. Die Möglichkeiten sind nachfolgend aufgeführt.

4.1.1 Netzwerkverkehr mitschneiden 1.) Gesamten Webverkehr des Rechners mitschneiden: Wählen Sie ihr Standardnetzwerkinterface (vermutlich »eth0« oder »wlan0«) aus und surfen Sie danach mit dem Webbrowser auf beliebigen Webseiten13. Kehren Sie anschließend zu Wireshark zurück und beenden Sie den Mitschnitt durch Klick auf den roten Stopp-Button. 2.) Webanmeldung innerhalb der Testumgebung mitschneiden: Sie wählen das Interface »Loopback lo« aus, öffnen anschließend den Browser und navigieren auf die Seite unserer DVWA-Testumgebung: http://127.0.01/dvwa Melden Sie sich in der Loginmaske mit den festgelegten Logindaten (Standard: admin/password) ein. Wechseln Sie anschließend wieder zu Wireshark und beenden den Mitschnitt durch Klick auf den roten StoppButton. 3.) Gesamten Netzwerkverkehr über den Router mitschneiden Einige Router unterstützen den Mitschnitt des Netzwerkverkehrs an zentraler Stelle. Prüfen Sie am besten im Handbuch Ihres Routers, ob Sie diese Option auch haben. An dieser Stelle nutzen wir die Mitschnitt-Funktion von Fritzboxen, diese ist unter folgender URL erreichbar: http://fritz.box/html/capture.html

Bild 4.2: Beispiel für mitschnittfähige Schnittstellen einer Fritzbox

Innerhalb des Webinterfaces der Fritzbox hat man anschließend die Möglichkeit, entweder bestimmte Netzwerkleitungen, etwa ausschließlich WLAN oder LAN, oder bestimmte Internetleitungen mitzuschneiden. Entscheiden Sie sich für das Interface, welches Sie nutzen und klicken auf »Start«, um den Mitschnitt einzuleiten. Anschließend können Sie einige Webseiten abrufen (wie im ersten Beispiel erwähnt am besten auch unverschlüsselte Webseiten). Durch einen Klick auf »Stopp« wird der zuvor gestartete Download der eth-Datei beendet. Die Datei kann zur weiteren Analyse innerhalb von Wireshark geöffnet werden.

4.1.2 Netzwerkverkehr auswerten Sie können unabhängig von der gewählten Methode (siehe letztes Unterkapitel) folgenden Filter über die Mitschnitte legen: http

Dadurch werden ausschließlich Pakete, die das HTTP-Protokoll nutzen, angezeigt. An dieser Stelle sollten nun einige an Webseiten durchgeführte Anfragen wiedererkennbar sein. Eine initiale Anfrage an eine Webseite lässt sich beispielsweise daran erkennen, dass ein GET / HTTP/1.1 im Bereich »Info« zu entnehmen ist. Eine Antwort ist (bei Erfolg) an dem Infotext HTTP/1.1 200 OK (text/html)14 zu erkennen.

Bild 4.3: HTTP-Anfrage und Antwort von »spiegel.de«

Mit folgendem Filter kann man ausschließlich Daten selektieren, welche per POST-Methode übertragen wurden: http.request.method == "POST"

Bild 4.4: Mitgeschnittene Informationen aus einem POST Request

Wie man dem Screenshot entnehmen kann, sind die Logindaten unserer Testumgebung einschließlich eines »user_token« zugänglich. Wichtig ist an dieser Stelle, dass durch Man-in-the-Middle-Angriffe die Session-ID ausgelesen werden kann. Was man mit der Session-ID genau anfangen kann, betrachten wir im nächsten Unterkapitel.

4.2 Cookie-Replay-Angriff

Bei einem Cookie-Replay-Angriff wird die zuvor erlangte Information der Session-ID verwendet, um sich gegenüber der Anwendung als legitim auszuweisen. Die Problematik beginnt, wenn es gelingt, eine gültige SessionID eines anderen Nutzers zu senden, denn so kann man sich gegenüber der Applikation als dieser Benutzer ausweisen und womöglich auf sämtliche Inhalte und Funktionen des Nutzers zugreifen. Ein »Cookie-Replay-Angriff« kann vergleichsweise harmlose Auswirkungen haben, etwa das Auslesen eines Einkaufswagens eines nicht angemeldeten Benutzers. Liegt allerdings eine Session-ID vor und kann diese ausgelesen werden, so ist die Übernahme der gesamten Sitzung denkbar (siehe dazu das nächste Unterkapitel). Dem Angreifer kann zum Vorteil gereichen, dass die Time-out-Zeiten recht großzügig sind. Vergisst dann ein Nutzer das Log-out oder schließt den Browser unbeabsichtigt (auch durch Absturz etc.), kann das dazu führen, dass die Sitzung gültig bleibt. Wenn überdies die Abmeldefunktion oder das Session-Management generell falsch implementiert ist, kann es sogar sein, dass die Session-ID nie abläuft. Findet ein Angreifer solche noch unbeabsichtigt gültigen Session-IDs, etwa durch Ausprobieren oder Sniffing, kann er mit dem »Cookie-Replay-Angriff« die alte (aber noch nicht abgelaufene) Sitzung erneut nutzen. Es gibt sogar Applikationen, die bewusst persistente Cookies einsetzen, damit der Nutzer sich nicht bei jedem Besuch der Webseite neu anmelden muss. Diese »Passwort merken«- oder »Erinnere dich an mich«-Checkboxen sind ein Risiko, denn wenn einmal eine Session-ID bekannt geworden ist, ist sie möglicherweise dauerhaft verwendbar, es sei denn, sie wird in bestimmten Zeitintervallen erneuert.

4.3 Session-Hijacking Beim Session-Hijacking (Sitzungsübernahme) geht es ebenfalls darum, Kenntnis über die gültige Session-ID anderer Nutzer zu erhalten und sie in einem Request an die Webapplikation zu senden, um sich als legitimer Nutzer auszugeben. Im Unterschied zum »Cookie-Replay-Angriff« geschieht das allerdings nicht zwingend im Nachhinein und unter Ausnutzung allzu großzügiger Ablaufzeiten der Sitzungen, sondern während ein Nutzer die

Applikation noch in Gebrauch hat. Doch wie kommen wir am besten an die Session-ID eines Nutzers? Eine naheliegende und simple Idee ist es, sie zu klauen. Dieses Vorgehen ist für Angreifer ein lohnender Ansatz, allerdings beschäftigen wir uns damit erst einige Kapitel später (siehe Kapitel 5, »Cross-Site-Scripting (XSS)«). Ein weiterer Ansatz wäre, Session-IDs zu erraten (»Brute-Forcing«), das wäre allerdings ebenfalls mit viel Aufwand verbunden, da die meisten Session-IDs standardmäßig recht lang sind. Statt mühsamen Ausprobierens ergibt es mehr Sinn, die Session-IDs (etwa die eigene) zu analysieren und mögliche Muster darin zu erkennen, um letztlich die Session-ID anderer Nutzer vorhersehen oder berechnen zu können. Teilweise wiegen sich Programmierer, denen es vorrangig um die Lauffähigkeit der Applikation geht, schon in Sicherheit, wenn eine ausreichend lange Session-ID vorliegt, beispielsweise 32-stellig (in PHP ist das ein gängiger Standard). Sie gehen davon aus, dass bei einer solchen Länge keine Gefahr durch »Session-Hijacking« besteht. Das ist jedoch weit gefehlt, denn es kommt nicht nur auf die Länge dieser Werte an, sondern vielmehr auf die Art, wie diese generiert werden. Würden Sie ein Passwort als sicher bezeichnen, das aus den ersten zehn Stellen der Fibonacci-Folge (11235813213455) besteht? Wohl kaum, da die Bildung dieser ID nicht geheim ist, sondern allseits bekannt: Die folgende Zahl ist immer die Summe der zwei vorherigen. Selbst bei einer Länge von über 1000 Stellen wäre ein solcher Code zu knacken, da man das Muster wiedererkennt und allgemeine Regeln in der Zahlenfolge ausmachen kann. Ähnlich kann das bei Session-IDs sein. Die Länge sagt also nichts über den Grad der Sicherheit bzw. Vorhersehbarkeit aus. Einem potenziellen Angreifer spielt an dieser Stelle noch etwas Anderes in die Hände. Die meisten Webapplikationen sind öffentlich zugänglich, was bedeutet, dass er sich selbst bei der Anwendung anmelden und seine eigene Session-ID auslesen könnte. Hat er sie, kann er sie möglicherweise zerlegen oder sogar rekonstruieren, wie sie gebildet worden ist. In Quellcodes von Webapplikationen finden sich zum Beispiel immer wieder Methoden, die den

Zeitstempel zur Erzeugung einer Session-ID oder eines eigentlich geheimen Schlüssels benutzen. Genau das war auch der Fall bei einem sehr verbreiteten Plug-in für das Content-Management-System WordPress. Die Mitarbeiter der Firma Sucuri Inc. entdeckten Anfang 2015 in dem Plug-In folgende Codezeile [11]: 'secret' => md5(time())

Konkret sorgt diese Zeile dafür, dass der Parameter secret den Wert der Zeit (Unix-Timestamp) in gehashter Form (MD5-Algorithmus, mehr dazu in den Kapiteln über Passworthashing; Kapitel 7.2 und 7.3) erhält. Das Fatale daran ist, dass diese Generierung vorhersehbar ist. Konkret: Ein Angreifer kann dieses Wissen nutzen, um sich den Parameter secret selbst zu generieren. In diesem Fall wurde der Parameter bei der Installation des Plug-Ins erzeugt, jeder, der also Kenntnis über den ungefähren Zeitraum der Installation hat (das Installationsdatum lässt sich häufig leicht ermitteln, etwa indem man auf andere Systemdateien prüft), ist in der Lage, den Parameter secret nachzuvollziehen. Mit diesem berechenbaren Wert war es schließlich sogar möglich, das gesamte Content-Management-System zu übernehmen. Das WordPress-Plug-In wurde zuvor rund 1,3 Millionen Mal heruntergeladen, von einem Augenblick auf den anderen waren also Millionen von Webseiten unsicher. Das Beispiel zeigt eindrucksvoll, was es bedeuten kann, wenn man auch nur einen sensiblen Wert mit vorhersehbaren Elementen generiert. Bezogen auf die zuvor behandelte Generierung von Session-IDs bedeutet das, dass wir es tunlichst vermeiden sollten, uns Werten zu bedienen, die für andere leicht zu erraten oder vorhersehbar sind15. Das folgende Bild zeigt eine Webapplikation, bei der die Entwickler offensichtlich sehr einfallslos waren, als es darum ging, zufällige Werte zu erzeugen. Ein erfahrenes Auge sieht sofort: Sie haben einfach den Timestamp des Unix-Systems genommen, um die Parameter id und secureToken zu generieren — also genau das gemacht, wovon gründlich abzuraten ist, denn einem Angreifer ist es damit möglich, diese Daten auszuprobieren und eventuell Sessions zu übernehmen.

Bild 4.5: Weba nwendung mit voraussagbaren GET-Parametern.

Nachfolgend finden Sie eine Liste, die häufig genutzte Werte zur Generierung von Session-IDs aufzeigt. Von deren alleiniger Verwendung soll jedoch ausdrücklich abgesehen werden (Tipps zur korrekten Generierung von Session-IDs erfolgen am Ende des Kapitels):

● IP-Adresse des Nutzers ● Referrer ● Hostname ● Zeitstempel ● simple Zahlenfolgen ● statische Werte ● User-Agent

● Nutzername oder weitere Daten des Nutzers Der Grund dafür, dass solche Werte häufig zum Einsatz kommen, ist, dass sie zufällig erscheinen und leicht im Quellcode aufrufbar sind. In der Praxis kommen häufig auch Kombinationen aus diesen Werten vor — etwa Zeitstempel + gehashter Benutzername. Trotz der scheinbaren Komplexität bleiben diese Werte vorhersehbar, und findige Angreifer können eventuell durch einfaches Betrachten der IDs bereits auf die Idee zur Generierung zukünftiger IDs kommen. Letztlich geht es darum, den »Zufall« vorauszusagen und dieses Wissen zu nutzen. Wurde die Methodik hinter der Generierung der Session-IDs unserer Applikation einmal durch einen Angreifer unbemerkt geknackt, ist letztlich unsere gesamte Nutzerauthentifizierung umgehbar, da die Session-ID jedes Nutzers unbemerkt generiert und auch verwendet werden kann.

Bild 4.6: Skizzierung einer Session-Übernahme.

Das Praktische für den Angreifer an den beiden ersten Angriffsarten ist, dass keine Notwendigkeit besteht, das eigentliche (möglicherweise starke)

Passwort eines Nutzers zu knacken, es genügt, seine Session-ID zu kennen, um seine Berechtigungen zu erhalten.

4.3.1 Session-Hijacking in der Praxis Um Session-Hijacking in der Praxis durchzuführen, benötigen wir die Kenntnis über eine gültige Session und einen Webbrowser, in dem die Session verwendet werden kann. Begeben wir uns also wieder an unsere Testumgebung. Dort öffnen wir entweder einen kurz zuvor angefertigten Mitschnitt (wie im Kapitel 4.1, »Man-in-the-Middle-Angriff« gezeigt), der eine gültige Session-ID aufweist oder führen die folgenden Schritte aus. Zunächst einmal starten wir Wireshark: wi reshark

Anschließend wählen wir das Interface »Loopback lo« aus und öffnen durch diesen Befehl den Chromium-Browser: chromium

Ist der Browser geladen, so können wir zu unserer Testumgebung navigieren, dazu geben wir in die Adresszeile http://127.001/dvwa ein. Den Login nehmen wir mit den uns bekannten Logindaten (admin/password) vor. Wir lassen diesen Browser geöffnet und minimieren ihn. Anschließend wechseln wir zu Wireshark und geben dort folgenden Filter ein: http

Nach der Eingabe werden uns ausschließlich HTTP-basierte Anfragen bzw. Antworten angezeigt. Wir suchen nun die Response, nachdem die gültigen Nutzerdaten übermittelt wurden, und klicken die entsprechende HTTPResponse an, dadurch sehen wir einen »Set-Cookie«-Befehl.

Bild 4.7: Set-Cookie innerhalb einer HTTP-Response

Innerhalb des mitgeschnittenen Pakets ist erkennbar, dass einem Parameter mit dem Namen »PHPSESSID« ein Wert zugewiesen wird. Wird dieser Wert auch in Cookies folgender HTTP-Requests genutzt, so ist davon auszugehen, dass es sich um die SessionID handelt. Wir können diesen Wert zunächst einmal aufschreiben und innerhalb von Wireshark den Mitschnitt beenden, indem wir auf den roten Stopp-Button klicken. Den Chromium-Browser, in dem sich die aktive Session befindet, lassen wir weiterhin geöffnet und starten nun den Mozilla Firefox. Dort navigieren wir ebenfalls zur DVWA: http://127.001/dvwa Anschließend wählen wir mit Rechtsklick »Inspect Element« (deutsch: »Element untersuchen«) aus. Dadurch öffnet sich der Entwicklerbereich des Browsers. Wir wählen den Reiter »Network« (deutsch: »Netzwerkanalyse«). Die möglicherweise vorhandenen Requests löschen wir durch einen Klick auf den kleinen Papierkorb. Anschließend klicken wir auf »Reload« (deutsch: »laden«) und wählen schließlich den Request »login.php« bzw. »index.php« aus. Im rechten Bereich werden schließlich Details zur Anfrage angezeigt.

Bild 4.8: Details zum HTTP-Request

Nun können wir auf »Edit and Resend« (deutsch: »Bearbeiten und erneut senden«) klicken und erhalten die Möglichkeit, entsprechende Werte zu

verändern. Statt dem vorhandenen Wert für PHPSESSID fügen wir nun den Wert ein, den wir zuvor aus dem Mitschnitt ausgelesen haben.

Bild 4.9: Details zum HTTP-Request

Anschließend ist nur noch ein Klick auf »Send« (deutsch: »Senden«) notwendig, und schon liegt im Mozilla Firefox die Session vor, welche zuvor durch den Chromium-Browser genutzt wurde. Dass die Sitzungsübernahme erfolgreich war, können wir auch daran erkennen, dass in der linken unteren Ecke von DVWA steht, dass wir als »admin« angemeldet sind.

Bild 4.10: Details zum HTTP-Request

Es gibt eine Vielzahl weiterer Tools, welche es ermöglicht, die Cookies bzw. Session-IDs zu ändern (siehe dazu mehr im Kapitel 14, »Tools«).

4.4 Session-Fixation

Ein weiterer Angriffsvektor im Bereich des Session-Managements ist die sogenannte Session-Fixation. Dabei handelt es sich um das Vorgehen, einem Nutzer eine HTTPSitzung förmlich aufzuzwingen oder unterzuschieben, und zwar noch vor einem Login. Der Vorgang wurde bereits 2002 von Mitja Kolsek beschrieben [12]. Trotzdem gibt es diese Schwachstelle immer noch in einigen Webapplikationen. Die Idee besteht darin, eine Session zu erstellen und dann das Opfer durch Anklicken eines Links die Session-ID erhalten zu lassen. Anschließend kann das bereits oben beschriebene Vorgehen genutzt werden, um die Sitzung zu übernehmen. Grundsätzlich müssen wir uns noch einmal darauf zurückbesinnen, wie die Übertragung von Session-IDs vonstatten geht, und erinnern uns an dieser Stelle zum Beispiel an die Übertragung mittels URL. Wir versetzen uns zunächst in die Lage des Angreifers und loggen uns zum Beispiel bei unserer Bank ein. Nach dem Log-in erhalten wir folgende beispielhafte URL (mit unserem Session-ID-Parameter): meine.bank/Login.aspx?sessionID=BwGAh0cAA3AAUBtxiVUPMEBAW Wir wissen, dass unser Opfer ebenfalls sein Konto bei dieser Bank hat, und schicken ihm eine Phishing-E-Mail mit einem Link zu der oben angeführten URL. Da diese tatsächlich die seiner Bank ist, denkt sich das Opfer nicht viel dabei, klickt den Link an und loggt sich ein. In dem Moment hat er sich gegenüber der Webapplikation identifiziert. Da wir als Angreifer aber seine Session-ID kennen, können wir uns ebenfalls gegenüber der Webapplikation als dieser Nutzer ausweisen (Session-Hijacking/Cookie-Replay). Wir haben also zunächst erfolgreich seine Session fixiert und konnten dann die Session komplett übernehmen bzw. uns als der Nutzer ausgeben, da dieser sich mit seinem Benutzernamen und seinem Passwort authentifiziert hatte.

Bild 4.11: Skizze einer Session-Fixation.

4.5 Session-Riding bzw. CSRF (Cross Site Request Forgery) Abschließend gehen wir auf das sogenannte Session-Riding bzw. Cross Site Request Forgery (CSRF, selten auch XSRF) ein. Session-Riding wurde in einem Whitepaper von Thomas Schreiber im Jahr 2004 erstmals näher beschrieben [13] und bezeichnet ein Vorgehen, welche das Vertrauen einer Webanwendung gegenüber einem angemeldeten (authentifizierten) Anwender ausnutzt. Konkret wird die zuvor getroffene Authentifizierung des Anwenders genutzt, um ohne sein Wissen eine Aktion, etwa den Kauf einer Ware, durchzuführen. Oft werden Session-Riding und Cross Site Request Forgery synonym verwendet. Ganz richtig ist das jedoch nicht, denn Cross Site Request Forgery (nachfolgend CSRF genannt) ist ein Verfahren, bei dem generell mittels HTTP-Anfrage Änderungen an der Webseite durchgeführt werden können, etwa das Ändern der Sprache. Session-Riding bezeichnet konkret

das Ausnutzen einer gültigen Sitzung mit gültiger Authentifizierung, etwa um Nutzerinformationen zu ändern. Insoweit muss Session-Riding als Unterart von CSRF angesehen werden. Ein recht harmloses Beispiel für Session-Riding ist das Log-out einer Webanwendung. Es gibt eine Vielzahl von Möglichkeiten, Nutzer auf eine Webseite zu locken, zum Beispiel mittels »Kurz-Link«. Bei einem Log-out-Link wie https://unsere.bank/index.php?action=logout mag das noch harmlos sein und allenfalls die Sitzung eines einzelnen Nutzers kurzzeitig stören, denn ein Klick erklärt die Session-ID für ungültig und beendet damit die Sitzung. Was ist jedoch, wenn auch komplexere Befehle mit einem Link abgesetzt werden können? Dann wird diese Lücke zu einer großen Gefahr. Prominente Beispiele dafür finden sich viele: So war es beispielsweise bis 2008 bei Amazon möglich, einfach Artikel in die Warenkörbe anderer Kunden zu legen [14], ohne dass diese das merkten. Das Perfide an dieser Art von Angriff ist, dass der simple Aufruf einer Drittwebseite, während man selbst in einem anderen Browser-Tab auf der verwundbaren Webseite eingeloggt ist, zum Ausführen eines unerwünschten Befehls führen kann. Durch Benutzung sogenannter »Hidden Iframes« (versteckte Browserfenster) ist es dem Angreifer möglich, die entsprechende Abfrage für den normalen Nutzer unerkennbar im Hintergrund einer anderen Webseite abzusenden. Mit letzterer Thematik werden wir uns später (siehe Kapitel 11, »UI-Redressing«) noch einmal ausführlich beschäftigen. Auch denkbar ist folgende Einbindung:

Dadurch wird die Aktion durchgeführt, ohne dass dies dank »Styling« mit display:none dem Opfer angezeigt wird. Jetzt wollen wir jedoch noch einmal einen Blick auf das Vorgehen bei einer CSRF bzw. dem Session-Riding werfen. Zunächst gehen wir davon aus, dass sich das Opfer gegenüber der Anwendung normal ausweisen kann. Es

handelt sich also um eine gültige Sitzung, die zum Beispiel mittels Cookie zustande kommt.

Bild 4.12: Gültige Sitzung zwischen einem Client und einem Webserver

Nehmen wir an, die Anwendung auf dem Webserver ist anfällig für CSRF, konkret für Session-Riding, bei dem es möglich ist, Geld von einem Account zu einem anderen zu transferieren. Da wir der Angreifer sind, möchten wir das Geld natürlich im Idealfall auf unser Konto übertragen. Wir senden dem Nutzer also einen gekürzten Link oder eine Phishing-E-Mail (siehe Abschnitt »Phishing-Angriffe« in Kapitel 10.3.12, »Soziale Manipulation (Social Engineering)«) und verlinken auf eine Webseite von uns, die im Hintergrund den Befehl zur Übertragung enthält. Wir könnten den Nutzer, falls die Anfrage mittels GET-Abfrage übertragen wird, natürlich auch direkt die Aktion ausführen lassen, ihm also den Link anzeigen. Die Wahrscheinlichkeit, dadurch direkt entdeckt zu werden, ist jedoch deutlich größer. Deshalb führen die meisten Angreifer die Befehle lieber im Hintergrund aus (etwa auf kompromittierten oder eigens dafür angelegten Webseiten). Nach dem Abruf unserer manipulierten Webseite wird die eigentliche Aktion dann mittels Anfrage im Hintergrund durchgeführt — damit war der Angriff per Session-Riding erfolgreich. Dass solche Lücken, obwohl ihr grundsätzliches Schema seit 2004 bekannt ist, immer noch nicht ernst genommen werden, zeigt ein aktuelles Beispiel von GoDaddy, dem weltgrößten Domainregistrator. Dylan Saccomanni entdeckte im Januar 2015 eine Lücke, die es ihm ermöglichte, Domains mittels Cross Site Request komplett zu übernehmen [15]. Konkret war Saccomanni in der Lage, mittels POST-Requests die sogenannten Namenserver zu ändern, damit hätte er eine Vielzahl von Domains unbemerkt

übernehmen können — ein Paradebeispiel dafür, dass die Unsicherheit einer kritischen Webapplikation auch andere Applikationen in erheblichem Maß gefährden kann.

Bild 4.13: Skizzierung: Session-Riding.

4.6 Zusammenfassung: Abhilfe aus Entwicklersicht Es scheint offensichtlich, dass beim Session-Management eine ganze Reihe von Maßnahmen getroffen werden muss, um Session-Angriffe zu unterbinden. Sonst haben Angreifer nahezu freie Hand, unsere Webapplikation in Gefahr zu bringen.

Im Folgenden sind die wichtigsten Abhilfen und Tipps aus Entwicklersicht zusammengefasst.

4.6.1 Verschlüsselung Grundsätzlich sollte bei Webanwendungen immer eine Verschlüsselung im Einsatz sein, um die Möglichkeit eines Man-in-the-Middle-Angriffs auszuschließen bzw. auf ein Minimum zu senken. Bei Webapplikationen, bei denen persönliche Daten oder Log-in-Daten verarbeitet werden, sollte immer eine Verschlüsselung zum Einsatz kommen (HTTPS). Es ist stets darauf zu achten, moderne Verschlüsselungen zu verwenden, aktuell bedeutet das im Idealfall die Verschlüsselung TLS 1.2 oder, falls nicht anders möglich, TLS 1.1. Die Nutzung von TLS 1.0 in neuen Systemen sollte vermieden werden, da es mittlerweile als veraltet gilt. Des Weiteren sollte »HTTP Strict Transport Security« (HSTS)16 genutzt werden. Dabei handelt es sich um ein Vorgehen, bei dem dem Nutzer direkt eine verschlüsselte Verbindung angeboten wird, auch wenn dieser eine unverschlüsselte Verbindung anfragt. Die Anwendung dieser Technologie ergibt Sinn, da heutzutage nahezu alle Endgeräte und Browser verschlüsselte Verbindungen unterstützen und die Sicherheit vor Man-in-the-MiddleAngriffen und Session-Übernahmen dadurch verbessert werden kann. Das entsprechende Cookie kann so gesetzt werden und wird von allen modernen Browsern unterstützt: Strict-Transport-Security: max-age=16070400; includeSubDomains

Bei Verschlüsselung handelt es sich eher um eine unterstützende Maßnahme, sie verhindert ausschließlich das Auslesen der Session-ID durch Dritte während der Übermittlung — Schutz vor vorhersagbaren Session-IDs oder anderen Angriffsvektoren ist dadurch noch nicht gegeben.

Auf verschlüsselten Webseiten sollten ausschließlich Inhalte eingebettet sein, die ebenfalls über verschlüsselte Verbindungen abgerufen werden können. Wird die Einbettung über eine unverschlüsselte Verbindung vorgenommen, gefährdet das möglicherweise die Geheimhaltung der Session-ID.

Um sicherzustellen, dass die Session-IDs vom Client immer über einen verschlüsselten Kanal gesendet werden, bietet es sich an, bei Setzen des Cookies eine Secure-Flag zu platzieren. Set-Cookie: auth=172d046067681c6a5f5b7039434b868; Path=/accounts; Expires=Wed, 15 Jan 2020 12:37:49 GMT; Comment=Testcookie; Secure; …

Die meisten Plattformen oder Server lassen in ihrer Konfiguration zudem zu, dass man dieses Verhalten grundsätzlich einschalten kann.

4.6.2 Sichere Generierung von Session-IDs Kern des Session-Managements ist die Session-ID. Die Geheimhaltung und Zufälligkeit der ID bestimmt die Sicherheit in besonderem Maße. Deshalb sollte darauf geachtet werden, dass die Session-IDs nicht aus Werten generiert werden, die vorhersagbar sind (siehe Übersicht in Kapitel 4.3, »Session-Hijacking«). Es ist sinnvoll, erprobte Funktionen zur Generierung von IDs aus Frameworks zu nutzen und nicht seine eigenen (möglicherweise unsicheren) Methoden zu erstellen. Die oben genannten Session-ID-Names (siehe Tabelle in Kapitel 4, »Session-Angriffe«) und Verfahren zur Generierung gelten allesamt als sicher. Falls doch notwendig, ist es wichtig zu wissen, dass die random()-Funktion einiger Programmiersprachen nur bedingt zufällig ist. Für Computer ist es schwer, »zufällige« Werte zu generieren. Immer wieder können Sicherheitsexperten nachweisen, dass manche Zufallsgeneratoren nicht so sicher bzw. zufällig sind wie angenommen. Insoweit empfiehlt sich bei der Generierung einer eigenen Session-ID die Nutzung eines nicht zufälligen Werts, etwa des Zeitstempels und einer zufälligen Zahl. Durch die Kombination aus zufälligem und nicht zufälligem Wert in der Session-ID wird Vorhersehbarkeit weitestgehend verhindert. Es sollte also keine voraussagbare Session-ID vorliegen und erst recht keine im Quelltext statisch codierte. Die Länge der Session-IDs ist ebenfalls wichtig — je länger eine ID ist, desto schwerer ist sie zu erraten (Mittel gegen Brute-Forcing). In der Praxis hat sich

eine Länge von etwa 128 Bit (16 Byte) bewährt (je nach System und Anwendung).

4.6.3 Sonstige Maßnahmen Bei jeder neuen Anmeldung an eine Webapplikation (Autorisierung mittels Nutzername/Passwort) sollte eine neue Session-ID vergeben werden. Wie bereits erwähnt, sollte das Log-in mit einer verschlüsselten Seite stattfinden und nicht erst nach dem Log-in auf den verschlüsselten Bereich weitergeleitet werden. Es muss durch eine Vorabüberprüfung ausgeschlossen werden, dass bereits ein Nutzer die generierte Session-ID nutzt, um Session-Fixation vorzubeugen und um Kollisionen bei der Vergabe der IDs zu vermeiden. Es sollte keine Übertragung der Session-ID über die URL geben. Besser ist die Verwendung von POST-Anfragen oder die Übertragung mittels Cookie. Die Übertragung sollte nicht über die URL stattfinden, da das zum einen die Session-Fixation erheblich erleichtert. Zum anderen gibt es sehr viele Systeme, welche die entsprechenden URLs in ihre Listings übernehmen. So lassen sich in Google mit den richtigen Suchparametern unzählige Webseiten mit Session-IDs in der URL finden (siehe Abschnitt »Google-Dorking« in Kapitel 10.3.11, »Suchmaschinen«), und es gibt vereinzelt Sitemaps oder Analysetools, in denen URLs versehentlich mit Session-ID gelistet werden. Beides ist für Angreifer ein »gefundenes Fressen«, denn bei einer hohen Anzahl von Session-IDs fällt die Analyse auf Schwachstellen in der Generierung deutlich leichter, und wenn der Angreifer Glück hat, kann er sogar noch gültige Session-IDs finden. Links auf externe Seiten könnten zur Folge haben, dass über den Referrer die Session-ID mit übertragen wird. Dadurch wäre die Geheimhaltung der Session-IDs fehlgeschlagen und eine Verwendung des Wissens in Form von Session-Hijacking durch den Besitzer der verlinkten Seite, ohne Weiteres möglich. (Gängige Tracking-Tools wie »Piwik« ermöglichen das Auslesen eines Referrers bereits in Echtzeit.)

Die Nutzung von sogenannten »http-only-Flags«17 empfiehlt sich ausdrücklich. Durch das Setzen dieses Werts ist kein Zugriff mehr auf das Cookie über JavaScript bzw. das DOM möglich — sondern nur noch über HTTP(S). Dadurch können also unter anderem XSS-Attacken unterbunden werden, die wir im nächsten Kapitel genauer betrachten möchten (siehe Kapitel 5, »Cross-Site-Scripting (XSS)«). Das Setzen der httponly-Flag für Cookies wird folgendermaßen durchgeführt: 001

// Implementierung in PHP (Standardwert ab PHP 5.3)

002

session.cookie_httponly = True

003 004 005

// Implementierung in VB.NET Dim myCookie As HttpCookie = new HttpCookie("myCookie")

006

myCookie.HttpOnly = True

007

Response.AppendCookie(myCookie)

008 009 010

//Implementierung in Java Cookie cookie = getMyCookie("myCookieName");cookie.setHttpOnly(true);

011 012

//Implementierung in Java mittels web.xml

013

014

015

true

016

017

Die allermeisten Browser unterstützen dieses Headerfeld und vermeiden sowohl den Schreib- als auch den Lesezugriff mittels Skriptsprache auf das betreffende Cookie. Dadurch können Manipulationen, etwa das Abschalten von anderen Sicherheitsmaßnahmen wie secure, durch Angreifer unterbunden werden.

Beim Session-Management spielen Zeitbeschränkungen eine wichtige Rolle. Die zeitliche Länge der Session sollte angepasst sein und es sollte klare Regeln zur Zeitüberschreitung geben. Wenn ein Nutzer zu lange keine Aktion mehr ausgeführt hat, sollte ein automatisches Log-out erfolgen, bei dem die Session als abgelaufen gekennzeichnet wird. Die Zeit bis zum sogenannten Session-Time-out (Zeitüberschreitung/ automatisches Log-out) sollte immer kürzer sein als die Zeit, die nötig ist, um die Session-ID zu erraten. Diese Gültigkeitszeit hängt immer auch von der Art der Applikation ab; beim Onlinebanking ist eine kürzere Session-Dauer sinnvoller als in einem Diskussionsforum. Nach etwa 20 Minuten ohne Nutzerinteraktion sollte die Sitzung jedoch bei jeder Art von offener Webapplikation mit Log-in-Funktion beendet werden. Wenn lange Sitzungen die Regel sind, beispielsweise bei aufwendigen Webapplikationen mit vielen Daten, scheint es Sinn zu ergeben, die SessionID bei jeder Anfrage zu ändern. Kommt ein Angreifer allerdings einmal an die gültige Session-ID, kann er den legitimen Nutzer »aussperren«, indem er die Seite schneller als dieser aufruft. Insoweit erweist sich das Konzept der nach jedem neuen Seitenaufruf generierten Session-IDs als nicht sinnvoll. Um dem Nutzer die Möglichkeit zu geben, die Sitzung auch korrekt zu beenden, wenn die Session-ID nicht mehr vonnöten ist (etwa bei Nichtmehrbenutzung der Webseite), sollte jede Applikation einen sichtbaren »Log-out-Button« haben. Der »Log-out-Button« sollte sich stets an der gleichen, möglichst auffälligen Stelle befinden (meist oben rechts). Wenn sich ein Nutzer nicht ausgeloggt hat (aus Unachtsamkeit, wegen zu langer Wartezeit oder durch einen Abbruch der Verbindung), sollte er beim nächsten Login darauf aufmerksam gemacht werden, dass er aus Sicherheitsgründen automatisch ausgeloggt wurde (seine Session-ID als ungültig erklärt wurde) und er die Log-out-Funktion aus Sicherheitsgründen immer nutzen sollte.

Bild 4.14: Hinweis einer Webseite, wenn bei der letzten Sitzung kein Log-out durchgeführt wurde.

Die Änderung von Daten, die für ein Login notwendig sind, wie etwa Passwort oder E-Mail-Adresse, sollte immer nur mit Eingabe des gültigen Passworts möglich sein. Dadurch macht man es Angreifern nahezu unmöglich, den Account komplett zu übernehmen, selbst wenn der Zugriff auf die Session-ID (über welchen Weg auch immer) gelungen ist (dazu später mehr in Kapitel 7, »Sicherheit von Authentifizierungs mechanismen«). Bei jeder Anmeldung eines Nutzers sollte eine neue Session-ID generiert werden, und es sollte nicht auf eventuelle Altdaten zurückgegriffen werden. Die Sitzung beginnt meist, sobald der Nutzer sich einloggt, deshalb sollte auch dann eine Session-ID generiert werden.

4.6.4 Hinweise zu Session-Riding bzw. CSRF Durch CSRF ergeben sich einige Schwierigkeiten, denn ist der Nutzer einmal gegenüber einer Anwendung authentifiziert, »denkt« diese, dass sämtliche Aktionen auch vom Benutzer ausgehen. Wir haben allerdings gelernt, dass das nicht sein muss, da einige Angriffe auf Anhieb durchgeführt werden — also beispielsweise im Hintergrund mittels Iframe oder durch den einfachen Klick auf einen Link.

CSRF funktioniert übrigens nicht nur via GET-Anfragen, sondern ebenfalls mit POST, denn mittels JavaScript kann man das Abschicken eines Formulars einfach vortäuschen. Falls Sie also bisher davon ausgegangen sind, dass das Nutzen von POST vor CSRF schütze, sei an dieser Stelle ausdrücklich gesagt, dass das nicht der Fall ist. Auch das Erstellen nach mehrstufigen Verfahren schützt nicht vor CSRF, sämtliche Bestätigungsdialoge können, sofern nicht korrekt vor CSRF geschützt, durch CSRF durchgeführt werden. Wir werden später den XSSWurm »Samy« kennenlernen, der genau von diesem Vorgehen, also der Kombination von CSRF und XSS, Gebrauch gemacht hat. Doch was schützt tatsächlich vor CSRF? Der simpelste Ansatz ist wohl das Prüfen des Referer-Headers. Ist er von einer anderen Domain, kann sicher davon ausgegangen werden, dass es sich um einen Angriff mittels CSRF handelt. Allerdings werden durch striktes Einhalten von HTTPS die Referer-Header heutzutage nicht mehr immer übertragen. Daher bietet sich dieses Vorgehen nicht wirklich für die Abwehr von CSRF an. Zudem besteht mittels XSS die Möglichkeit, eine Manipulation dieses Headers vorzunehmen. Weitere Maßnahmen, Session-Riding bzw. CSRF zu unterbinden, wären die Nutzung von zusätzlichen Abfragen, etwa CAPTCHAs (siehe Kapitel 7, »Sicherheit von Authentifizierungsmechanismen«), One-Time-Tokens (bekannt aus dem Bankingbereich — TANs) oder eben durch erneute Eingabe des Passworts. Diese Maßnahmen sind allerdings nicht besonders nutzerfreundlich und nur für Webapplikationen zu empfehlen, bei denen erhöhte Sicherheitsmaßnahmen notwendig erscheinen. Die letzte und mittlerweile am weitesten verbreitete Abhilfe kann ein sogenanntes CSRF-Token schaffen. Das Praktische an diesem Vorgehen ist, dass der Nutzer davon nicht besonders viel mitbekommt. Die Webapplikation erstellt ein zufälliges Token, das mit der Session-ID des Nutzers logisch verknüpft wird. Bei jeder Anfrage übergibt der Nutzer dieses Token, etwa mittels eines versteckten Formularwerts: 001

002



003

…

004

005

Wenn eine Aktion ausgeführt wird, muss die Webapplikation nur noch prüfen, ob es sich bei dem übermittelten CSRF-Token um den erwarteten Wert handelt. Ist das der Fall, ist sichergestellt, dass die Anfrage legitim vom Nutzer kommt. Wie bei der Generierung von Session-IDs ist die Sicherheit des CSRFSchutzes von der Länge und Komplexität des Tokens abhängig, also sollten große und zufällige Zahlen gewählt werden. Beispiele zum Generieren des CSRF-Tokens sind beispielsweise: $token = base64_encode(rand()) $token = md5(openssl_random_pseudo_bytes(32))

Am benutzerfreundlichsten und sichersten erscheint also die Generierung des bereits erwähnten CSRF-Tokens. Das CSRF-Token sollte einmalig für eine Sitzung eines Nutzers sein, in jeder neuen Session sollte es ein neues CSRFToken geben. Damit ein Angreifer nicht die Möglichkeit hat, möglicherweise abgefangene CSRF-Tokens zu nutzen, bietet es sich zudem an, für jedes Formular ein neues CSRF-Token zu generieren — das kann allerdings problematisch sein, wenn der Nutzer verschiedene Tabs nutzt. Der Einsatz von CSRF-Tokens ist äußerst ratsam, und es gibt mittlerweile viele Open-Source-Projekte, die sich einfach in bestehende Projekte integrieren lassen. Beispielhaft genannt sei »NoCSRF« für PHP. Manche Frameworks bieten zudem bereits umfassende Lösungen. So gibt es in ASP.NET die Hilfsmethode HtmlHelper. Für Java EE gibt es beispielsweise eine Bibliothek mit dem Namen »CSRFGuard Project«, und in Ruby on Rails lässt sich auf csrf_meta_tag zurückgreifen, sofern man die »jquery-ujs«-Bibliothek nutzt.

12

Wireshark selbst wird in Kapitel 14,: »Tools« noch einmal genauer vorgestellt.

13

Auch solchen, die nicht mittels TLS/SSL verschlüsselt sind, deren URL also nicht https enthält.

14

Die HTTP-Codes ergeben sich aus dem RFC 7231. Sie sind zudem im kostenlosen BasiswissenKapitel dieses Buches einsehbar: https://hacking-im-web.de/basiswissen.pdf

15

Die NSA (National Security Agency) hat in der Vergangenheit mehrfach auf kryptografische Funktionen oder kryptografische Standards eingewirkt, um diese bewusst zu schwächen - dabei wurde oft der Raum für mögliche Zufallszahlen klein gehalten, sodass der »Zufall« keiner mehr ist: https://www.heise.de/security/meldung/NSA-Affaere-Generatoren-fuer-Zufallszahlen-unter-der-Lupe1953716.html

16

Früher hieß diese Technologie einmal STS (Strict Transport Security).

17

Viele Entwickler verwirrt die Bezeichnung »http-only«: Sie bedeutet nicht, dass Inhalte über HTTP statt HTTPS übertragen werden.

5 Cross-Site-Scripting (XSS) Einen weiteren gängigen Angriffsvektor gegen Webapplikationen stellen XSSAngriffe dar. XSS bedeutet Cross-Site-Scripting18 und bezeichnet konkret die Injektion von ausführbarem Code auf Webseiten. Oftmals kommt bei XSS-Angriffen JavaScript zum Einsatz, da es von den meisten Clients bzw. Browsern unterstützt wird und somit die Zahl möglicher Opfer für den Angreifer äußerst attraktiv ist. Es gibt aber auch die Möglichkeit, mit anderen Skriptsprachen (etwa VBScript) XSSAngriffe durchzuführen, das ist jedoch eher selten und nur bei äußerst gezielten Angriffen der Fall. Bevor wir uns die Angriffsvektoren anschauen, sei gesagt, dass XSS lange Zeit unterschätzt oder von Entwicklern belächelt wurde, tatsächlich kann es jedoch sehr schwere Auswirkungen haben. Der Mythos, dass mit XSS keine Webapplikation »zerstört« oder »übernommen« werden kann, stimmt so auch nicht, denn XSS bietet eine Vielzahl von Möglichkeiten. Gerade durch die Kombination mit anderen Angriffsvektoren, beispielsweise dem bereits bekannten »Cookie-Replay-Angriff« (siehe Kapitel 4.2, »Cookie-Replay-Angriff«), kann man großen Schaden anrichten.

5.1 Reflexives XSS Eine klassische XSS-Attacke ist die des reflexiven Cross-Site-Scripting (auch »nicht persistentes XSS« genannt). Da Webapplikationen oft die Eingabe eines Nutzers wieder ausgeben, hat dieser die Möglichkeit, den Inhalt indirekt oder direkt zu beeinflussen. Bei harmlosen Eingaben hat das keine weiteren Auswirkungen, aber wenn sich Angreifer daran zu schaffen machen, kann es negative Folgen haben. Nehmen wir einmal in einem Beispiel an, dass die Übergabe eines Parameters zur Ausgabe in der URL mittels GET erfolgt: http://adresse.domain/suche.php?name=test

Wie wir der URL entnehmen können, handelt es sich offenbar um ein Skript zur Suche (suche.php). Viele Suchfunktionen nutzen insbesondere dann, wenn es keine Treffer gab, folgende Ausgabe auf der Ergebnisseite: »Keine Treffer zu test gefunden.« Die Applikation funktioniert also augenscheinlich, wie sie soll: Es wird kein Ergebnis ausgegeben und darauf verwiesen, dass unter dem gesuchten Stichwort (test) nichts zu finden ist. Der Quellcode dazu sieht so aus:

Keine Treffer zu test gefunden.

Wenn der Wert völlig ungefiltert auf der Ergebnisseite zurückgegeben wird, ist es möglich, ein reflexives XSS zu platzieren. Die Reflexion des XSS besteht darin, dass eine Anfrage an den Server geschickt wird und dass der Anfragende anschließend eine Antwort erhält, in welche der zuvor übermittelte Schadcode eingebettet, also reflektiert wurde.

In unserem Beispiel mit der Suchfunktion müsste man also nur folgenden Code in das Suchfeld eingeben: "> — und schon würde das eingefügte JavaScript ausgeführt werden. “> dient in diesem Fall dazu, das vorherige Tag so gut wie möglich zu schließen. Die Zeile mit dem Ergebnis im Quellcode sieht dann folgendermaßen aus:

Keine Treffer zu "> gefunden.

In diesem Fall wird ein harmloser alert-Befehl von den Skript-Tags eingeschlossen, also eine Anzeigebox mit dem Textinhalt XSS erzeugt. Das Einfügen dieses Befehls dient als Beweis (Proof of Concept, PoC), dass auch weiteres Einschleusen von Skripten möglich wäre.

Bild 5.1: Bildschirmfoto der typischen Java-Script-Pop-up-Box in Mozilla Firefox.

Statt des genannten Befehls sind, wie angesprochen, auch weitaus schlimmere Szenarien möglich, etwa das Klauen von Cookies mittels »Cookie-Replay-Angriff« (siehe Kapitel 4.2, »Cookie-ReplayAngriff«), um Benutzeraccounts zu übernehmen, oder das Einschleusen eines Keyloggers in JavaScript, um Tastatureingaben auf der Webseite zu protokollieren. Die URL sieht nach einer Suchanfrage mit injiziertem Code folgendermaßen aus: http://adresse.domain/suche.php?name=">

Jeder Browser, in dem diese URL aufgerufen wird, führt das injizierte JavaScript aus.19 Ein Diebstahl des Cookies ist recht simpel und könnte etwa folgendermaßen vonstattengehen:

Der Code muss in der URL platziert werden, und ein potenzielles Opfer mit aktiver Sitzung (Session-IDCookie) muss ihn anklicken. Dabei muss der Angreifer nur ein Skript zur Verfügung stellen, das den übergebenen Parameter document.cookie (einen Parameter aus dem DOM) verarbeitet (im Beispiel oben steal.php). Eine direkte Verwendung des Cookies ist mit Browsererweiterungen wie Tamper Data erschreckend einfach. Zum Testen einer Webapplikation oder zum Erstellen eines Proof of Concept sollte man nicht unbedingt direkt die Session-IDs klauen, zudem ist das nicht immer möglich (mehr dazu bei den Abhilfen). Es ist sinnvoller, Befehle wie:

zu nutzen (Ausgabe der Domain in einer JavaScript-Pop-up-Box), denn wenn sie erfolgreich sind, ist ohnehin klar, dass beliebiger JavaScript-Code eingeschleust werden kann.

Bild 5.2: Skizzierung: reflexives Cross-Site-Scripting mit Cookie-Klau.

Das Vorgehen eines reflexiven XSS mit Cookie-Klau sieht wie folgt aus: ➊ Das Opfer loggt sich normal in eine Webapplikation ein. ➋ Der Angreifer hat eine reflexive XSS-Lücke gefunden und erstellt einen manipulierten Link, der etwa so aussehen könnte: http://adresse.domain/suche.php?name=">

➌ Das Opfer klickt auf den Link oder ruft ihn unwissentlich (versteckte Einbindung als Iframe etc.) auf. ➍ Der Server sendet die Seite mit dem Schadcode an das Opfer. ➎ Der Browser des Opfers führt folgenden Schadcode aus:

➏ Dadurch wird die Session-ID an den Angreifer gesendet. ➐ Durch die Kenntnis der Session-ID kann der Angreifer die Session übernehmen (»Cookie-ReplayAttacke«). XSS kann also in Kombination mit dem Stehlen von Cookies sehr interessant sein. Rufen wir uns erneut ins Gedächtnis, dass es einige Webapplikationen gibt, die auf persistente Session-Cookies setzen (siehe Kapitel 4, »Session-Angriffe«), wird schnell deutlich, dass XSS ein mächtigerer Angriffsvektor sein kann, als zunächst angenommen.

Was schafft Abhilfe bei solchen XSS-Angriffen? Man muss verhindern, dass Code, der vom Nutzer eingegeben wurde, durch den Browser interpretiert wird. Einige findige Programmierer kamen einmal auf die Idee, das Wort script einfach zu verbieten bzw. zu filtern, indem sie es aus der Eingabe des Nutzers ausschnitten. Auf den ersten Blick ein kluger Gedanke, auf den zweiten allerdings totaler Unfug, und zwar aus mehrerlei Gründen: Zum einen könnte man, falls das

Somit erlangen wir die Möglichkeit, einen ausführbaren JavaScript-Code zu platzieren, und das ist zunächst einmal alles, worum es einem potenziellen Angreifer geht. Dass das Scripting geringfügig aufwändiger ist, spielt nach einer erfolgreichen Attacke keine Rolle mehr. Der andere Grund, warum die oben erwähnte Filterung von script völlig wirkungslos gegen Angreifer wäre, ist der, dass nicht nur mittels der script-Tags JavaScript eingefügt werden kann. Zum Beispiel könnte auch folgender Code genutzt werden:

Eigentlich handelt es sich dabei um ein Eventattribut für SVGs (Scalable Vector Graphics), das nur beim erfolgreichen Laden von Grafiken ausgeführt wird. Zahlreiche Browser führen das JavaScript trotzdem direkt aus. XSS ist überwiegend ein Problem der jeweiligen Anwendung und nicht des Browsers, denn Letzterer interpretiert nur den Code, den er erhält. Hat ein Angreifer also seitens des Entwicklers die Möglichkeit erhalten, Code zu injizieren, ist das ein Fehler aufseiten der Applikation. Neben dem eben erwähnten onload gibt es zahlreiche weitere HTML-DOM-Events. Die wichtigsten sind hier aufgelistet. Sie können sehr hilfreich bei der Erzeugung von sogenannten XSS-Payloads sein: Mausevents:

● onclick (Event wird ausgeführt, wenn ein Klick auf das Element stattfindet) ● onmouseover (Event wird ausgeführt, wenn die Maus auf dem Element ist) ● onmouseleave (Event wird ausgeführt, wenn die Maus das Element verlässt) ● onmouseup (Event wird ausgeführt, wenn die Maustaste losgelassen wird) Tastaturevents:

● onkeydown (Event wird ausgeführt, wenn eine Taste gedrückt bleibt)

● onkeypress (Event wird ausgeführt, wenn eine Taste gedrückt wird) ● onkeyup (Event wird ausgeführt, wenn eine Taste losgelassen wird) Frame- oder Objektevents:

● onpageshow (Event wird ausgeführt, wenn eine Seite aufgerufen wird) ● onscroll (Event wird ausgeführt, wenn gescrollt wird) ● onunload (Event wird ausgeführt, wenn eine Seite verlassen wird) Formularevents:

● onfocus (Event wird ausgeführt, wenn ein Element ausgewählt wird) ● oninput (Event wird ausgeführt, wenn der Nutzer etwas eingibt) ● onsearch (Event wird ausgeführt, wenn der Nutzer einen Suchbegriff in ein Such-feld eingibt) Es kann also zum Beispiel auch eine Injektion von JavaScript mit einem Link durchgeführt werden: XSS Link

Sobald die Maus über den Link fährt, wird in diesem Beispiel ein JavaScript-Pop-up mit einer 1 erzeugt. Natürlich sind auch Varianten ohne alert denkbar, zum Beispiel eine recht komplexe mit einem Iframe und einer verschachtelten JavaScript-while-Schleife:

Eine andere Variante leitet den Nutzer einfach auf eine beliebige Seite weiter oder öffnet ein neues Fenster, zum Beispiel mit: 001

// Öffnet einen neuen Tab mit google.com:

002

003

// Leitet auf test.com weiter:

004

"

Falls die Eingaben des Nutzers serverseitig oder in einem Flash-Cookie (auch LSO, Local Shared Object) gespeichert werden, kann das aufgezeigte Verhalten sogar zu persistentem XSS führen. DOM-based XSS ist auch mittels Flash möglich, allerdings ist diese Konstellation äußerst selten und sollte mit dem bereits bekannten Wissen adaptierbar sein. Das genaue Vorgehen wird deshalb an dieser Stelle vernachlässigt. Wir betrachten nun mögliche Abhilfen zu den uns bekannten XSS-Angriffsvektoren.

5.8 Abhilfe aus Entwicklersicht Wer sich jetzt noch fragt, warum man als Angreifer bei XSS-Attacken das Opfer nicht direkt auf eine beliebige Webseite weiterleitet und dort schädliches JavaScript hinterlegt, sollte sich nochmal vergegenwärtigen, wie mächtig die Umgehung der Same-Origin-Policies (SOP) ist. Neben der Übernahme von Sessions durch Cookie-Klau ist es mittlerweile bei Angreifern sehr beliebt, Webseiten mit XSS zu verunstalten. So werden immer wieder große Webseiten oder Firmen durch das Einbinden von entsprechenden Fotos kompromittiert, weil die Applikation das zulässt. In dem Zusammenhang wird häufig die Kommentarfunktion in HTML genutzt, um die normale Webseite auszublenden: 001

002

…

003

004

Text

005

// Injektionspunkt (in diesem Fall wird ein Kommentartag geöffnet)

006