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 darüber 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?

Es ist kaum abzusehen, welchen Imageschaden und welche finanziellen Auswirkungen solche erfolgreichen Angriffe nach sich ziehen können. Allerdings ist das, was hier als Schreckgespenst an die Wand gemalt scheint, für viele Firmen bereits Realität geworden.

Das wohl prominenteste Beispiel für die gravierenden Folgen eines Hackerangriffs ist der sogenannte »Sony Pictures Entertainment Hack« im Jahr 2014. Bei diesem Hack gelang es Unbekannten, in die internen Netze des Filmstudios Sony Pictures einzudringen. Später wurden interne E-Mails, Aliasnamen von Schauspielern, Drehbücher, Passwörter, Sozialversicherungsnummern von Angestellten und sogar unveröffentlichte Filme im Internet zugänglich gemacht. Der Schaden wurde von Sony auf 15 Millionen US-Dollar beziffert [1]. Dieser Hack ist damit wohl als bisher größter bzw. gravierendster Hack anzusehen.

Trotz alledem hat sich recht wenig getan, schließlich lesen wir solche Nachrichten immer wieder und fragen uns, wie das nur möglich sein kann.

Umso wichtiger ist es, dass Sie sich mit Ihren Systemen beschäftigen und solchen Angriffen präventiv begegnen, indem Sie sie sichern.

1.1Der Ansatz

In diesem Buch soll mithilfe eines pragmatischen Ansatzes gezeigt werden, wie die Programmierung einer sicheren Webapplikation möglich ist. Anhand realer Sicherheitslücken und von Codebeispielen wird deutlich gemacht, wie schnell man einer sicher geglaubten Webanwendung habhaft werden kann. Um dies zu zeigen, wird immer wieder die Position eines potenziellen Angreifers eingenommen. Dadurch soll die Bedrohung realistisch nachgeahmt, und zugleich verdeutlicht werden, dass es keine Bedrohung ist, die nur durch IT-Profis in die Tat umgesetzt werden kann, sondern täglich tausendfach stattfindet und für jeden möglich ist, der genug Zeit aufwendet und Interesse aufbringt.

1.2Das 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 schnell 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 sich nicht damit zufriedengeben, wenn eine Funktionalität wie gewünscht implementiert wurde, sondern erst, wenn sie ausschließlich wie gewünscht verwendet werden kann und »sicher« ist.

1.3Der 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 werden die technischen Grundlagen umfassend erklärt (siehe Kapitel 3, »Basiswissen«), um das Verständnis der darauffolgenden Kapitel zu ermöglichen. Wir werden das zugrunde liegende Protokoll behandeln, ein Augenmerk auf die gängigsten Sprachen des Webs legen und auch Technologien wie den Webbrowser betrachten.

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 vielen 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 tiefer gehend 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 kritisch zu betrachten sind, sehen wir uns in Kapitel 10, »Informationspreisgabe«, an.

Vor einigen Jahren wurde Cross-Site-Scripting belächelt — mittlerweile haben allerdings die meisten erkannt, 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 falsch, denn Clickjacking bedroht die Nutzer direkt, teilweise sogar so perfekt, dass man als Seitenbetreiber kaum etwas davon mitbekommt. Es gibt jedoch Abhilfe (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 daran halten würde, wäre schon viel in puncto Websicherheit gewonnen (siehe Abschnitt 13 »Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche«).

Zudem gibt es einige Anhänge:

Der erste und gleichzeitig längste Anhang ist jener 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 Anhang A, »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 Anhang B näher beleuchten (siehe Anhang B, »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 Anhang C behandeln (siehe Anhang C, »Legal Webhacking durchführen«).

Das Internet der Dinge oder Kontrollsysteme von Industrieanlangen sind längst vernetzt und lassen sich auch über das Web steuern. Wir möchten in Anhang D über sogenanntes SCADA-Hacking sprechen und sehen, welche Angriffsmöglichkeiten sich daraus ergeben (siehe Anhang D, »SCADA-Hacking«).

Das war es so weit auch schon mit den einzelnen Kapiteln und Anhängen. 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.4Die...