Zum Abschluss des Themenkomplexes "Schwachstellensuche in Webanwendungen" gibt es eine Zusammenfassung aller notwendigen Schritte. Los geht es mit dem

Sammeln von Informationen

über die zu untersuchende Webanwendung sowie die verwendete Infrastruktur wie z.B. den Webserver. Zuerst werden dazu alle Seiten der Anwendung einmal durchlaufen (siehe About Security #144). Die dabei gesammelten Informationen werden dann ausgewertet: Gibt es versteckte Informationen, die weitere Aufschlüsse über die Webanwendung zulassen? Welche Parameter werden wo/wie eingesetzt? Kommen sie für Cross-Site-Scripting- und/oder SQL-Injection-Angriffe in Frage, erlauben sie vielleicht Directory-Traversal-Angriffe oder Local/Remote File Inclusion? Ist evtl. ein Pufferüberlauf möglich? ... (#145). Danach geht es auf die Suche nach versteckten Informationen wie nicht verlinkten Dateien, bevor der Client an der Reihe ist. Je nachdem, ob es sich dabei um statische Seiten handelt, in denen im wesentlichen nur nach Informationen gesucht wird (#146), oder ob es sich um einen dynamischen Ajax-Client handelt, in dem auch selbst Schwachstellen vorkommen können (#147), ist dafür mehr oder weniger Aufwand notwendig (#148).

Die gesammelten Informationen werden dann für die Suche nach Schwachstellen verwendet. Als erstes geht es dabei um

Zustandsbasierte Angriffe

Da HTTP ein zustandsloses Protokoll ist, müssen die von der Webanwendung benötigten Zustände auf dem Server und/oder dem Client gespeichert werden. Selbst wenn die eigentlichen Zustände auf dem Server gespeichert werden, enthält der Client i.A. Informationen, über die er vom Server erkannt wird, meist in Form einer Session-ID oder eines ähnlichen Werts. Auf dem Client kann die Speicherung der Zustandsinformationen oder der Session-ID z.B. in versteckten Formularfeldern (#149), URL-Parametern (#150) oder Cookies (#151) erfolgen. Manipulationen an solchen Werten muss die Webanwendung verhindern oder zumindest erkennen, was am Beispiel des Cookie Poisoning beschrieben wird (#152). Ein weiterer möglicher Angriff ist das URL Jumping (#153), vor dem auch die Auswertung des manipulierbaren Referer-Headers nicht schützt (#154). Werden die Zustandsinformationen auf dem Server gespeichert und der Client anhand z.B. einer Session-ID erkannt, kann ein Angreifer diese evtl. über Session Hijacking übernehmen (#155). Session Hijacking kann man durch verschiedenen Maßnahmen verhindern (#156), die aber nicht vor Session Fixation schützen. Dafür sind wieder andere Gegenmaßnahmen erforderlich. (#157).

Als nächstes geht es um Angriffe über vom Benutzer gelieferte Daten, zuerst um

Cross-Site-Scripting-Angriffe

Einfache XSS-Schwachstellen lassen sich schon durch die Eingabe von <script>alert('XSS')</script> finden (#158). Vorhandene Filter können evtl. umgangen werden, was etwas mehr Aufwand erfordert (#159). Zum Finden solcher Schwachstellen sind verschiedene Testmuster und Vorgehensweisen notwendig (#160). Es gibt verschiedene Möglichkeiten, XSS-Schwachstelle zu verhindern, die sich teilweise aber auch mit mehr oder weniger viel Aufwand umgehen lassen (#161). Während es zuerst überwiegend um reflektiertes XSS ging, ist danach persistentes XSS an der Reihe, bei dem der XSS-Code z.B. in Kommentaren gespeichert wird (#162). Zum Finden solcher Schwachstellen bieten sich zwei Wege an: Entweder die Parameter werden einer nach dem anderen mit immer dem gleichen Testmuster geprüft, oder es werden gleichzeitig für alle Parameter individuelle Testmuster eingegeben (#163). Außer normalen Parametern gibt es noch verschiedene andere Möglichkeiten, XSS-Code in die Webanwendung einzuschleusen (#164). Genau anders herum funktioniert DOM-basiertes XSS, bei dem sich die Schwachstelle im clientseitigen Code befindet und der Schadcode mit der Webanwendung gar nicht oder nur am Rande in Berührung kommt (#165).

Nach den XSS-Angriffen geht es um

SQL-Injection-Angriffe

SQL-Injection-Schwachstellen verraten sich oft durch eine SQL-Fehlermeldung (#166), die folgenden Schritte sind abhängig vom Parameter und dem vorhandenen SQL-Statement: Je nachdem, ob der erwartete Wert ein String (#167) oder eine Zahl (#168) ist, ob es ein SELECT-, INSERT- oder UPDATE-Statement (#169) ist, die weiteren Schritte müssen auf die vorhandenen Umstände eingehen. Das gilt auch für DELETE-Statements oder die Möglichkeit, über UNION zusätzliche SELECT-Statements in ein vorhandenes SELECT-Statement einzuschleusen (#170:, #171). Vorhandene Filter für die Parameter lassen sich evtl. umgehen (#172), das gilt teilweise auch für das Escapen der Eingaben (#173). Machmal ist zwar keine direkte SQL-Injection möglich, dafür aber SQL-Injection 2. Ordnung, bei der gespeicherter SQL-Injection-Code in einem späteren Schritt ausgeführt wird (#174). Ein Spezialfall ist die Blind SQL-Injection, bei der das Ergebnis des SQL-Statements nicht ausgegeben wird, aber zwischen richtigen und falschen Eingaben unterschieden werden und der Datenbank darüber Ja/Nein-Fragen gestellt werden können (#175). Um SQL-Injection zu verhindern, verwendet man am besten parametriesierte Aufrufe von Prepared Statements (#176).

In der nächsten Folge wird diese Zusammenfassung fortgesetzt.

Carsten Eilers