Systematische Schwachstellensuche in Webanwendungen
Abgeklopft
Penetrationstests sind eine gängige Methode, Webanwendungen auf Schwachstellen zu prüfen und den Handlungsbedarf zu dokumentieren. Der Arbeitsaufwand lässt sich mit viel Disziplin und der Beachtung von Regelwerken im Zaum halten.
Wer eine Anwendung vor allem auf bekannte oder offensichtliche Schwachstellen hin abklopft, sollte methodisch vorgehen, um ein möglichst vollständiges und für Außenstehende nachvollziehbares Ergebnis zu erzielen. Außerdem hilft eine gute Methodik, die für den Test vorgesehene Zeit sinnvoll einzuteilen und bestmöglich zu nutzen. Um die bekanntesten Regelwerke geht es im Folgenden.
Der Testing Guide des Open Web Application Security Project (OWASP), kurz OTG, liegt mittlerweile in Version 4 vor [1]; die Überarbeitung für Version 5 läuft. Der Hauptteil, Kapitel 4, ist in Prüfbereiche wie INFO oder INPVAL gegliedert. Diese enthalten eine unterschiedliche Zahl detaillierter Prüfpunkte, etwa INPVAL-001 (Testing for Reflected Cross-Site Scripting), INPVAL-002 (Testing for Stored Cross-Site Scripting) et cetera. Jeder Prüfpunkt kann wiederum aus mehreren Schritten bestehen. Hier und da mangelt es dem OTG leider an Übersichtlichkeit, weil die Beschreibung der einzelnen Schritte teilweise widersprüchlich oder unsystematisch ist oder weil sich einige Punkte überlappen.
Darüber hinaus stimmen die Gewichtungen im OTG nicht immer. Einige Punkte sind sehr detailliert ausgearbeitet und mit konkreten Hinweisen zum Vorgehen versehen (etwa INPVAL-005 – SQL-Injection), andere Punkte sind ziemlich kurz abgehandelt. So erfordert CONFIG-007 kaum mehr als zu prüfen, ob der Server den Header „Strict Transport Security“ mit plausiblen Parametern verwendet. Einige Punkte des OTG sind zudem sorgfältiger strukturiert und enthalten zum Beispiel einen Abschnitt „Testing Objective“. Außerdem fehlen Prüfpunkte zu Angriffen wie Template Injection oder Server-Side Request Forgery, die durch einige moderne Architekturen inzwischen relevant sind.
Neben dem OTG existiert der OWASP Application Security Verification Standard (ASVS) [2], die aktuelle Version ist 3.0.1, die Arbeiten an Version 3.1 sind im Gang. Der ASVS unterscheidet zwischen den Levels 1, 2 und 3 respektive „Opportunistic“, „Standard“ und „Advanced“. Hinzu kommt Level 0, „Cursory“, der einer willkürlichen Prüfung entspricht, ohne einem definierten Schema zu folgen. Die Prüfpunkte von Level 1 bilden eine Teilmenge derjenigen von Level 2, die wiederum Teil der Prüfpunkte von Level 3 sind. Mit steigendem Level wächst also auch der Prüfumfang und damit – zumindest der Idee nach – die Gewissheit über das Sicherheitsniveau der geprüften Anwendung.
Engere Zusammenarbeit wünschenswert
Da sowohl der Testing Guide als auch der ASVS derzeit überarbeitet werden, wäre eine engere Kooperation zwischen beiden Projekten wünschenswert. Eines der Ziele für den kommenden ASVS lautet schließlich, die Prüfpunkte zwischen Level 1 und 2 so zu arrangieren, dass alle in Level 1 enthaltenen Prüfpunkte im Rahmen eines Penetrationstests prüfbar sind und alles darüber hinaus in Level 2 angesiedelt wird. Dieser Zustand ist noch nicht ganz erreicht. Im Idealfall ergäbe sich eine 1:1-Abbildung der OTG-Punkte auf diejenigen des ASVS Level 1.
Der ASVS unterscheidet sich vom OTG in einigen wichtigen Aspekten. So formuliert der ASVS für jeden Prüfpunkt eine klare Erwartung. Beinahe jeder beginnt mit „Verify that …“, zum Beispiel „V2.9: Verify that the changing password functionality includes the old password, the new password, and a password confirmation“. Insofern gibt der ASVS gleichzeitig einen Katalog für Sicherheitsanforderungen her. Der zweite Unterschied liegt darin, dass die Formulierung der Anforderung auch schon alles ist: Eine Erklärung zu den einzelnen Punkten oder Hinweise zur Prüfung sucht man im ASVS vergeblich, dabei bedürfen einige Punkte des ASVS der Erläuterung. Da nur eine Prüfung nach Level 1 als Penetrationstest gestaltet werden kann, ist im Folgenden mit ASVS stets der Level 1 gemeint.
Eine weitere Methodik stellt Kapitel 21 des Web Application Hacker’s Handbook vor ([3], kurz WAHH). Es ist sehr detailliert ausgearbeitet und außerdem erscheint es viel mehr als etwa der OTG wie aus einem Guss. Hinweise zum Vorgehen sind praktischerweise in den vorangehenden 17 Kapiteln dargestellt (die ersten drei Kapitel dienen der Einführung).
Das Open Source Security Testing Methodology Manual (OSSTMM), der Pentest Execution Standard (PTES) oder der Pentest-Leitfaden des BSI bleiben im Folgenden unberücksichtigt, denn OSSTMM und PTES blenden das Thema Webanwendungen komplett aus, und der BSI-Leifaden richtet sich an „alle Verantwortlichen in Unternehmen und Behörden“. Taktische Hinweise für Penetrationstester sucht man in diesen Dokumenten also vergeblich.