Hacking im Web 2.0

Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihren Webapplikationen

Tim Philipp Schäfers

• Verlag: Franzis Verlag
• Jahr: 2018
• ISBN:
  9783645224680
• Auflage: 2
• Thema: Computer Science
• Thema: Web Programming

Der Erfolg des E-Commerce hat auch seine Schattenseiten: Hackerangriffe im Web gehören inzwischen zum Alltag. Es geht dabei nicht nur um unsichere Firewalls oder Fehler in Betriebssystemen, häufig stellt die selbst programmierte Webapplikation das größte Einfallstor dar. Um sich vor Hackern zu schützen, ist es wichtig, wie ein Hacker zu denken. In diesem Buch lernen Sie die häufigsten Angriffsmethoden kennen und erhalten Tipps, wie Sie sich dagegen schützen können. Analysieren Sie Ihren Programmcode auf Schwachstellen und schließen Sie die Lücken gleich in der Implementierungsphase.Die wichtigsten AngriffsvektorenDurch die Kombination verschiedenster Technologien wie Browser, HTML, JavaScript, PHP, Java und SQL in Webanwendungen sind die potenziellen Schwachstellen quasi unzählbar. Ob SQL-Injection, Cross-Site-Scripting oder Session-Hijacking: Lernen Sie die Funktionsweise dieser Angriffe kennen, stellen Sie Ihr Können beim Angreifen der Testumgebung unter Beweis und schützen Sie sich mit den aufgeführten Tipps erfolgreich vor Angriffen.Werkzeuge kennen und nutzenEntwickler sind keine Sicherheitsexperten und können nicht jede Schwachstelle der eingesetzten Programmiersprache und Bibliotheken kennen. Umso wichtiger ist es, die entstandene Webanwendung auf ihre Schwachpunkte zu testen. Schäfers stellt in einem ausführlichen Anhang zahlreiche Werkzeuge vor, mit denen Sie effektiv nach Schwachstellen suchen können.

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, »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 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.¹

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 IT-Sicherheit 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 Change-Managements) 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 Anweisunge...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Danksagung
• Inhalt
• 1 Einleitung
• 2 Evolution des Webs
• 3 Einrichtung der Testumgebung
• 4 Session-Angriffe
• 5 Cross-Site-Scripting (XSS)
• 6 Angriffe auf nachgelagerte Datenbanksysteme
• 7 Sicherheit von Authentifizierungsmechanismen
• 8 File Inclusion
• 9 Logische Fehler
• 10 Informationspreisgabe
• 11 UI-Redressing
• 12 Weitere Angriffsarten
• 13 Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche
• 14 Tools
• 15 Bug-Bounty-Programme
• 16 Legal Webhacking durchführen
• 17 SCADA-Hacking
• Epilog
• Abkürzungsverzeichnis
• Literaturempfehlungen
• Quellenverzeichnis
• Index