1.2 Welche Schwachstellen gibt es?
Das Open Web Application Security Project (OWASP) veröffentlicht alle paar Jahre eine Liste mit den Top 10 der größten Bedrohungen für Webanwendungen [OWASP_Top10][ 1 ]. Aktuell ist derzeit die Version 2017, die im Herbst 2017 veröffentlicht wurde [OWASP_Top10-2017]. Aber wie es bei Top 10 üblich ist, gibt es noch viel mehr Bedrohungen, Schwachstellen, Angriffe ... Und ob die Top 10 wirklich so eine große Bedrohung sind, ist auch immer relativ. Auf Platz 4 stehen die XML External Entities (XXE). Für Webanwendungen, die XML gar nicht nutzen, ist das völlig harmlos. Was nicht da ist, kann auch nicht angegriffen werden.
Das ist aber auch nicht weiter schlimm, die OWASP Top 10 sollen ja gar nicht dazu dienen, z. B. Schwachstellentests zu planen oder die Sicherheit einer Webanwendung zu bewerten, sondern das Bewusstsein für diese Schwachstellen zu schärfen. Woraufhin diese hoffentlich seltener werden und dann irgendwann aus den Top 10 herausfallen.
Auch in dieser Version gab es einige Änderungen zur Vorgängerversion von 2013. So ist z. B. das Cross-Site-Scripting von Platz 3 auf Platz 7 gefallen, dafür ist der Punkt »Sensitive Data Exposure«/»Preisgabe sensibler Daten« von Platz 6 auf Platz 3 aufgestiegen. Die Cross-Site-Request-Forgery, die 2013 noch auf Platz 8 stand, ist inzwischen aus den Top 10 heraus und ungefähr auf Platz 13 gelandet [OWASP_Top10-2017-RC2]. Wenn Sie jetzt nur Bahnhof verstanden haben: Keine Angst, die ganzen Schwachstellen werde ich im Laufe des Buchs noch erklären.
Aber weil ich gerade von der Bewertung der Sicherheit von Webanwendungen geschrieben habe: Wieso muss ich da bloß immer an die Quartette aus meiner Kindheit denken? »Ich habe drei XSS und eine Sensitive Data Exposure« – »Und ich habe drei SQL-Injections und zwei OS-Command-Injections« – »OK, Du hast gewonnen, hier ist meine Karte. Du bist dran!«
Vermutlich, weil ich das für Spielerei halte. Jede Software und damit auch jede Webanwendung sollte möglichst gar keine Schwachstellen enthalten, egal, wie leicht oder schwer sie auszunutzen und wie gefährlich die Folgen eines Angriffs sind.
Natürlich ist es schlimm, wenn über z. B. eine SQL-Injection-Schwachstelle sämtliche Datenbanken ausgespäht werden. Aber was ist, wenn über eine persistente XSS-Schwachstelle Code zur Infektion der Rechner aller Besucher der Website eingeschleust wird – was ist dann schlimmer?
Im ersten Fall betrifft es einige Tausend registrierte Benutzer, deren Zugangsdaten und Kreditkartennummern von den Cyberkriminellen gehandelt werden. Im zweiten Szenario sind es einige zig Tausend arglose Besucher, deren Rechner nach dem Besuch mit einem Onlinebanking-Trojaner infiziert ist. Was ist schlimmer?
Oder vielleicht wurde die Webanwendung ja auch von einem Geheimdienst über einen Fehler in der Authentifizierung gezielt infiziert, um sie für den Angriff auf den Rechner eines Dissidenten zu präparieren? Sie wissen ja: Die Dissidenten und Terroristen der einen Seite sind für die andere unschuldig Verfolgte und Freiheitskämpfer. Wie soll man das bewerten?
Ich denke, wir sind uns hier einig: Jede einzelne Schwachstelle in einer Webanwendung ist eine zu viel. Und Ranglisten haben immer etwas Subjektives, über das man sich streiten kann.
1.2.1 Die OWASP Top 10
In den OWASP Top 10 vom 2017 [OWASP_Top10-2017] sind folgende Bedrohungen enthalten:
A1:2017 – Injection
Enthält Schwachstellen wie die SQL-Injection (siehe Kapitel 6), OS-Command- und SMTP-Injection (beide in Kapitel 7) und andere Schwachstellen, bei denen der Angreifer eigene Befehle in Interpreter und Ähnliches einschleusen kann
A2:2017 – Broken Authentication (gebrochene Authentifizierung)
Wer Benutzer hat, muss sie identifizieren können. Das nennt man Authentifizierung, und jeder Fehler darin erlaubt es einem Angreifer, sich als anderer Benutzer auszugeben und/oder unbefugt auf die Webanwendung zuzugreifen (siehe Kapitel 4, »Angriffe auf die Authentifizierung«).
A3:2017 – Sensitive Data Exposure (Preisgabe sensibler Daten)
Das ist ein weites Feld. Dazu gehören unverschlüsselt übertragene Zugangsdaten, die dann unterwegs belauscht werden können, oder offen zugängliche Dateien mit vertraulichen Daten (siehe z. B. Kapitel 6, »SQL-Injection«).
A4:2017 – XML External Entities (XXE)
Wird XML verwendet, kann es über XML External Entities manipuliert werden. XML und damit XXE kommen hier im Buch nicht vor.
A5:2017 – Broken Access Control (gebrochene Zugriffskontrolle)
Die Authentifizierung stellt sicher, dass Sie wissen, wer der Benutzer ist. Genauso wichtig ist aber die Zugriffskontrolle oder Autorisierung: Darf der Benutzer das, was er gerade machen will, überhaupt? Hier im Buch kommt das z. B. in Kapitel 3, »Zustandsbasierte Angriffe«, vor.
A6:2017 – Security Misconfiguration (sicherheitsrelevante Fehlkonfiguration)
Alles, was sich konfigurieren lässt, lässt sich auch unsicher konfigurieren, z. B. wenn für die TLS-Verschlüsselung unsichere Kryptoverfahren verwendet werden oder wenn ein eigentlich nötiger Passwortschutz vergessen wird, so dass Teile der Webanwendung frei zugänglich sind, statt wie geplant nur bestimmten Benutzern offenzustehen. Das kommt im Buch an verschiedenen Stellen vor.
A7:2017 – Cross-Site-Scripting (XSS)
Das Einschleusen von bösartigem JavaScript-Code in die Webanwendung erlaubt alle möglichen Angriffe, beispielsweise kann darüber der Benutzer ausgespäht oder sein Rechner mit Schadsoftware infiziert werden.
A8:2017 – Insecure Deserialization (unsichere Deserialisierung)
Werden Daten serialisiert gespeichert (vereinfacht werden dabei komplizierte Strukturen einfach hintereinander weg in eine Variable geschrieben), müssen sie später wieder deserialisiert, d. h. in die Ausgangsdaten zurückverwandelt werden. Ein Angreifer kann eine Schwachstelle dabei ausnutzen, um Daten zu manipulieren. Dies kommt im Buch nicht vor.
A9:2017 – Using Components with known Vulnerabilities (Nutzung von Komponenten mit bekannten Schwachstellen)
Wenn Sie die Demo-Anwendung als Blog in Ihre Webanwendung integrieren, haben Sie dieses Problem. Spaß beiseite: Hier geht es wirklich darum, dass z. B. Bibliotheken mit bekannten Schwachstellen verwendet werden. Das Problem sind dabei weniger die direkt genutzten Komponenten, die kennen Sie hoffentlich und können sie aktuell halten. Aber wie sieht es mit den Dritthersteller-Komponenten aus, die diese von Ihnen genutzten Komponenten verwenden? Wer sorgt dafür, dass diese immer in einer sicheren Version verwendet werden? Sie können das kaum, dazu müssten Sie nämlich wissen, welche Komponenten das sind, und wenn es ein Update gibt, prüfen, ob Sie das einfach so installieren können oder ob danach irgendetwas mit der Komponente nicht mehr funktioniert. Das wird nie was. Im Buch kommt dies Thema aber nicht vor.
A10:2017 – Insufficient Logging & Monitoring (unzureichende Protokollierung und Überwachung)
Das ist wie die XXE auf Platz 4 ein Neuzugang in den Top 10 2017. Da es sich weder um eine Schwachstelle in der Webanwendung noch um einen Angriff darauf handelt, passt es eigentlich nicht richtig in die Liste. Dabei ist es doch sehr wichtig, denn wenn Sie nicht merken, dass jemand versucht, Ihre Webanwendung anzugreifen, können Sie den Angriff auch nicht abwehren. Dieses Thema werde ich in Abschnitt 1.6 kurz behandeln.
1.2.2 Weitere Schwachstellen
Außerdem stelle ich im Buch Schwachstellen vor, die nicht in den Top 10 enthalten oder gerade hinausgerutscht sind, z. B. Clickjacking, das es nie in die Top 10 geschafft hat und unter dessen Variante »Likejacking« – Angriffe auf den »Like«-Button – Facebook sehr gelitten hat. Ich würde wetten, dass Mark Zuckerberg Clickjacking ziemlich weit oben in den Top 10 sehen würde. Auch die schon erwähnte CSRF, die 2017 aus den Top 10 ausschied, kommt im Buch vor.
1.2.3 Gliederung des Buchs
Die Gliederung richtet sich nach einem möglichen Vorgehen bei der Suche nach Schwachstellen: Zunächst erkunden Sie die Webanwendung, dann suchen Sie entweder systematisch schrittweise nach den verschiedenen Schwachstellen (wenn Sie alle finden möchten) oder gezielt...
