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:
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.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, »Session-Angriffe«).
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-Site-Scripting (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 UI-Redressing, 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...
