Web Application Penetration Testing - Eine Einführung

Web Application Penetration Testing

Eine Einführung

Andrea Hauser
von Andrea Hauser
am 24. Oktober 2019
Lesezeit: 10 Minuten

Keypoints

So lernen Sie Web Application Penetration Tests

  • Eine gute Vorbereitung ist für jeden Web Application Penetration Test notwendig
  • Die Festlegung des Scopes und der Erwartungen des Kunden sind entscheidend für eine erfolgreiche Durchführung
  • Neben manuellem Testing werden immer auch automatisierte Tools eingesetzt, um die Low-Hanging Fruits zu finden
  • Das allerwichtigste ist allerdings die Intuition des Testers

Bei diesem Artikel handelt es sich um den Begleitartikel zu meinem Talk vom 21. Oktober 2019 am Blackhoodie @HackLu. Dabei handelt es sich um einen Talk, der eine Einleitung ins Web Application Penetration Testing aus meiner persönlichen Sicht gibt. Es wird zuerst eine Einleitung über die notwendigen Vorbereitungen für einen Web Application Penetration Test gegeben und danach wird auf das Vorgehen während eines Web Application Penetration Test eingegangen.

Vorbereitungsphase

Bevor mit einem Web Application Penetration Test gestartet werden kann, muss zuerst die Testing-Umgebung aufgesetzt, sowie der Scope abgeklärt werden. Zusätzlich mache ich mir jeweils bereits zu Beginn schon Gedanken über die Reporting-Methode und bereite eine Checkliste aller zu testenden Bereiche vor. Dies um sicherzustellen, dass ich während dem Testing nichts vergesse, aber auch um mir die zu testenden Bereiche nochmals klar zu machen und allenfalls gewisse Defizite aufzuarbeiten, bevor der Test startet.

Ebenso wichtig wie ein vorbereitetes Testvorgehen anhand einer Checkliste ist das Sicherstellen, dass die Tools auf dem aktuellen Stand und einsetzbar sind. Für einen Web Application Penetration Test setze ich mindestens die folgenden Tools ein:

Ebenfalls ganz zu Beginn eines Projekts ist das Scoping vorzunehmen. Dabei geht es darum, sich mit dem Kunden über die Ausführung und die Ziele des Web Application Penetration Tests einig zu werden. Das Scoping wird mit dem Kunden zusammen in einem Kick-off Gespräch durchgeführt. Spätestens nach dem Kick-off Gespräch müssen folgende Fragen geklärt sein:

Damit sollten vor Beginn des Web Application Penetration Tests alle notwendigen Dinge abgeklärt sein.

Durchführung Web Application Penetration Test

Im Bereich von Web Application Penetration Testing existieren viele gute Ressourcen. Ich stütze mich vor allem auf die Ressourcen von OWASP unter anderem der OWASP Testing Guide sowie der OWASP Application Security Verification Standard.

Bevor ich mit dem Testen einzelner Schwachstellen beginne, schaue ich mir jeweils die Webapplikation einmal vollständig an und versuche möglichst mit allen Bereichen der Webapplikation zu interagieren. Dazu gehört auch das Auswerten von Unterschieden bei mehreren Benutzerrollen. Während diesem Browsen läuft im Hintergrund die ganze Zeit mein Proxy, damit ich danach in meiner History ein möglichst vollständiges Bild aller Requests und deren Responses habe. Bei diesem ersten Durchsehen der Applikation mache ich mir mentale Notizen zu interessanten Interaktionsmöglichkeiten, dazu gehören zum Beispiel Login-Masken und Suchfelder. Danach browse ich ein zweites Mal durch die Applikation und schaue mir dabei die ausgelösten Requests und deren Responses genauer an. Dies ebenfalls, um interessante Ziele für eine manuelle Überprüfung festzustellen.

Nach dieser ersten Übersichtsbeschaffung beginne ich dann damit einzelne, als interessant aufgetauchte Bereiche auf Schwachstellen zu untersuchen. Parallel dazu lasse ich automatisierte Tools gegen ausgewählte Endpunkte laufen. Es soll nicht davor zurückgewichen werden, automatisierte Tools während eines Web Application Penetration Test einzusetzen, denn diese können die Low-Hanging Fruits bereits aussortieren, damit sich der Tester auf komplexere Bereiche konzentrieren kann. Bei all den automatisierten Tools stelle ich allerdings immer sicher, dass ich eine History der ausgeführten Requests und Responses erhalte, um nach der Ausführung des Tools einen kurzen Blick darauf werfen zu können. Manchmal gibt es unerwartete Responses, die durch das automatisierte Tool nicht als solche erkannt werden, hier setze ich als Tester dann an und schaue mir das ganze manuell weiter an.

Mein Vorgehen bei einem Web Application Penetration Test soll nun anhand der Kategorie A1 – Injection aus der OWASP Top 10 – 2017 Schwachstellenliste aufgezeigt werden.

A1:2017 – Injection

Bei dieser Kategorie handelt es sich um ein sehr breites Feld, welches es zu testen gibt. Darunter befinden sich sämtliche Schwachstellen, die ein Angreifer ausnutzen kann, wenn er mit manipulierte Daten die Ausführung eines Befehls verändern kann. Dabei kann es sich unter anderem um manipulierte SQL-Statements, Betriebssystem-Befehle und vieles weiteres handeln. Das Erkennen einer solchen Schwachstelle soll anhand einer SQL-Injection Schwachstelle durchgespielt werden.

Im angenommenen Szenario wird ein Webshop untersucht. In diesem Webshop ist es möglich Produkte nach Kategorien zu filtern. Beim initialen Browsen des Webshops wurde festgestellt, dass ein normaler Request, der nach Kategorien filtert, wie folgt aussieht:

https://example.com/filter?category=Lamps

Was mir hier als Tester auffällt ist, dass der Kategoriefilter in der WHERE-Klausel eines SQL-Statements landen könnte. Damit werde ich hier sicher eine SQL-Injection versuchen. In einem ersten Versuch wird die klassische SQL-Injection ' OR 1=1-- verwendet. Ein Request würde dabei wie folgt aussehen:

https://example.com/filter?category='%20OR%201=1--

Nun gilt es die Response der Injection mit der Response eines ungefilterten Requests zu vergleichen. Falls sich in der Response zum Beispiel die Anzahl der angezeigten Produkte verändert hat, kann von einer erfolgreichen SQL-Injection ausgegangen werden.

Das Ganze würde im angenommenen Beispielszenario seitens Backend in etwa wie folgt aussehen:

String category = request.getParameter("category");
String query = "SELECT * FROM products WHERE category =' " + category + " ' AND released = 1";

Im Falle des Angriffs sieht das ausgeführte SQL-Statement schlussendlich wie folgt aus:

SELECT * FROM products WHERE category='' OR 1=1--

damit wird das limitierende AND released = 1 umgangen.

Weiterführende Beispiele können in unserem Artikel zum Thema SQL-Inection gefunden werden. Ein gutes Tutorial inklusive vielen Labs, bei denen die gezeigten Schwachstellen selbständig ausprobiert werden können, ist in der Portswigger Web Security Academy zu finden.

Um das Beispiel sauber abzuschliessen, wird nun noch aufgezeigt, wie die Schwachstelle in diesem Fall hätte verhindert werden können. SQL-Injections können unter anderem mit dem Verwenden von Prepared Statements verhindert werden. Im gezeigten Fall würde dies konkret wie folgt aussehen:

String category = request.getParameter("category");
String query = "SELECT * FROM products WHERE category = ? AND released = 1";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, category); 
ResultSet results = pstmt.executeQuery();

Injections im generellen können durch das Verwenden von sicheren API-Calls, dem Einsetzen von Whitelists und dem Escaping von sprachabhängigen speziellen Zeichen verhindert werden. Vertiefende Informationen dazu finden sich im Injection Prevention Cheat Sheet.

Schlusswort

Mit diesem Artikel sollte es einer interessierten Person möglich sein, einen ersten Einblick in den Ablauf eines Web Application Penetration Tests zu erhalten. Dabei ist wichtig, dass vor der effektiven technischen Untersuchung bereits eine gewissenhafte Vorbereitung mit der Festlegung des Scopes und der Ziele des Web Application Penetration Tests stattgefunden hat. Bei der Durchführung des Tests ist nicht nur das technische Know-How wichtig, sondern auch die Intuition des Testers, um interessante Bereiche zu identifizieren. Diese Intuition lässt sich auch als Person ohne IT-Security Job aufbauen, indem bei jeder besuchten Webseite die ausgelösten Netzwerk-Requests beobachtet werden. Damit lässt sich schon nach dem Besuch einiger weniger Webseiten ein Gefühl dafür kriegen, wie sich eine “normale” Webseite verhält.

Über die Autorin

Andrea Hauser

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
GraphQL

GraphQL

Andrea Hauser

Server-Side-Request-Forgery

Server-Side-Request-Forgery

Andrea Hauser

Policy Analyzer

Policy Analyzer

Andrea Hauser

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv