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:

• Kali Linux
• Browser, meist Firefox und Chrome
• BurpSuite Professional oder als kostenlose Alternative OWASP ZAP
• nmap

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:

• Was soll getestet werden (Ziel-URL, Benutzerrollen, usw.)?
• Ist die Webapplikation von extern erreichbar?
• Falls die Webapplikation nicht von extern erreichbar ist: Wo genau soll getestet werden?
• Wie viele Informationen werden dem Tester zur Verfügung gestellt?
• Wird der Test als Blackbox, Graybox oder Whitebox Test durchgeführt?
• Erhält der Tester Zugriff auf die Dokumentation und oder den Source Code?
• Falls Zugriff auf Dokumentation oder Source Code erlaubt wird: Bis wann werden die Dokumente dem Tester übergeben?
• Wie viele unterschiedliche Benutzerrollen bestehen?
• Werden dem Tester Test-Accounts zur Verfügung gestellt, oder können Accounts selbständig eröffnet werden?
• Bis wann werden allfällige Test-Accounts eröffnet und dem Tester zugestellt?
• Wann wird der Test stattfinden?
• Wie lange wird getestet?
• Bis wann werden erste Ergebnisse bzw. ein erster Draft des Reports erwartet?
• Was sind die Gründe für den Web Application Penetration Test?
• Was erwartet der Kunde vom Web Application Penetration Test?
• Was soll nicht getestet werden?
• Gibt es Bereiche, die nicht im Scope sind?
• Wer wird während der Durchführung des Tests die Ansprechperson sein?
• Wer ist bei schwerwiegenden Schwachstellen zu informieren?

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 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

• https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
• https://nmap.org/download.html
• https://portswigger.net/burp
• https://portswigger.net/web-security/sql-injection
• https://www.blackhoodie.re/HackLu_schedule/
• https://www.kali.org/downloads/
• https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/Main_Page
• https://www.owasp.org/index.php/OWASP_Testing_Project
• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• https://www.owasp.org/index.php/Top_10-2017_A1-Injection