Evaluation geeigneter Plugins im Bereich Web Application Vulnerabilities für die Integration ins ASTF

Transkript

1 Evaluation geeigneter Plugins im Bereich Web Application Vulnerabilities für die Integration ins ASTF Seminararbeit Eingereicht bei Dr. Marc Rennhard Kevin Denver Winterthur, 20. November 2008

2 Abstract Dieser Bericht wurde im Rahmen einer Seminarbeit für das MSE Studium am Institut für Angewandte Wissenschaften (InIT) geschrieben. Das Automated Security-Testing Framework (ASTF), welches im Rahmen eines KTI-Projekts am InIT entwickelt wurde, vereinigt verschiedene Security Testing- Tools, um Online-Applikationen konsequent und reproduzierbar bezüglich Sicherheit zu testen. Ein Bereich, der momentan nur ungenügend abgedeckt ist, ist die Detektion von typischen Web Application Vulnerabilities wie Cross-Site Scripting, SQL Injection etc. Dies soll im Rahmen dieser Seminararbeit untersucht werden. Es wurden 13 Vulnerability Scanner evaluiert und getestet, wobei kommerzielle wie auch OpenSource Produkte berücksichtigt wurden. Die Tools wurden anhand einer auf PHP und MySQL basierenden Versuchsanordnung getestet. Die identifizierten Kandidaten wurden am Schluss an einer Rich Internet Application nochmals getestet. Folgende drei OpenSource Produkte haben alle Anforderungen erfüllt und würden sich für die Integration ins ASTF eignen: w3af, wapiti und sqlmap. Bei w3af und wapiti handelt es sich um Frameworks, die nicht nur auf die Detektierung von Cross-Site Scripting und SQL-Injections ausgelegt sind. Sqlmap ist sehr stark in der Erkennung von Blind-SQL Injection Schwachstellen. i

3 Abstract This report was written at the Institut für angewandte Informationstechnologie (InIT) as a seminary work. The Automated Security Testing Framework (ASTF) which has been developed at the InIT as part of a KTI-Project, combines different security testing tools. ASTF is used to audit the security of online applications. The detection of typical web application vulnerabilities like Cross-Site Scripting and SQL Injection etc. is not optimally covered. The goal of this report is to identify commercial or free available web vulnerability scanner which can be integrated into ASTF. This report covers 13 web vulnerability scanners which have been tested using three rich internet applications and testcases solely written for this purpose. Following candidates have been identified to find most vulnerabilities: w3af, wapiti and sqlmap. These are all OpenSource products which can be integrated into ASTF. ii

4 Kontakt Zürcher Hochschule Winterthur c/o Institut für angewandte Informationstechnologie InIT Steinberggasse 13 Postfach 805 CH-8401 Winterthur Tel.: Fax: Name Kürzel Funktion Denver Kevin denk Student Rennhard Marc rema Betreuer & Advisor iii

5 Inhaltsverzeichnis 1 Einleitung Einführung und Motivation Ziel der Arbeit ASTF Plugin-System Wrapper-Klasse Technische Details zu Web Vulnerability Scanner Übersicht Fuzz Testing Webcrawler Detektierung von Schwachstellen Evaluation Bewertungskriterien Vorgehensweise Versuchsanordnung Dateistruktur Cross-Site Scripting (SS) SQL Injection Blind-SQL Injection wapiti w3af sqlmap Paros Proxy OWASP WebScarab Grendel-Scan Burp-Suite BSQL-Hacker iv

6 Inhaltsverzeichnis 3.12 Syhunt Sandcat Acunetix WVS Hewlett-Packard Scrawlr Milescan Web Security Auditor IBM Rational AppScan Standard Edition Testergebnisse Details zum Testergbniss von Syhunt Sandcat Details zum Testergbniss von Milescan Web Security Auditor Auswertung & Fazit Auswertung Test der Kandidaten an einer Rich Internet Application Unkonforme HTML Formulare Anhang 30 Abbildungsverzeichnis Tabellenverzeichnis Listings Literaturverzeichnis A Originale Aufgabenstellung 34 v

7 KAPITEL 1 Einleitung Dieses erste Kapitel soll die Motivation, Idee und das Ziel dieses Berichtes wiedergeben. Anschliessend wird das Plugin-System des ASTF Frameworks erläutert und die Anforderungen beschrieben, welche das Framework an Plugins stellt. 1.1 Einführung und Motivation Das Automated Security-Testing Framework (ASTF), welches im Rahmen eines KTI-Projekts am InIT entwickelt wurde, vereinigt verschiedene Security Testing-Tools, um Online-Applikationen konsequent und reproduzierbar bezüglich Sicherheit zu testen. Ein Bereich, der momentan nur ungenügend abgedeckt ist, ist die Detektion von typischen Web Application Vulnerabilities wie Cross-Site Scripting, SQL Injection etc. Dies soll im Rahmen dieser Seminararbeit untersucht werden. 1.2 Ziel der Arbeit Dieser technische Bericht evaluiert mögliche Applikationen, welche als Erweiterungen in das ASTF Framework integriert werden können. Die Applikationen werden auf ihre Funktionalität und Tauglichkeit untersucht. Dieser Bericht dient dem projektinternen Gebrauch und verzichtet deswegen auf die Erklärung von technischen Details bezüglich Cross-Site Scripting und SQL Injection Vulnerabilities. Weiterführende Literatur ist im Anhang angegeben. Kapitel 1. Einleitung 1

8 1.3 ASTF Plugin-System Das ASTF Framework ist in der Lage, externe Applikationen anzusprechen und deren Resultate in den vom ASTF Framework generierten Report einfliessen zu lassen. Damit das ASTF Framework eine Applikation integrieren bzw. als Plugin verwenden kann, muss diese vier Bedingungen erfüllen: Automatisierter Aufruf ohne Benutzerinteraktion Reproduzierbarkeit der Tests Erstellung eines Berichts / Reports Lauffähig unter Linux Kann je nach Installationsort variieren Das ASTF Framework verwendet eine in Java geschriebene Wrapper-Klasse, um eine externe Applikation als Plugin zu integrieren. Diese Wrapper-Klasse vereinheitlicht den Zugriff auf externe Applikationen und stellt nützliche Methoden und Funktionen bereit. Abbildung 1.1 verdeutlicht diesen Sachverhalt. Abbildung 1.1: ASTF Plugin System Sobald ein Testlauf durchgeführt wird, werden die gewünschten Plugins ausgeführt. Die von den Plugins erstellten Berichte bzw. Reports werden mit der Wrapper-Klasse in ein ASTF kompatibles Format konvertiert. Erstellt eine Applikation keinen Report bzw. generiert nur Konsolen-Output, kann dieser Output mit ein wenig Implementationsaufwand innerhalb des Wrappers abgefangen und konvertiert werden. Kapitel 1. Einleitung 2

9 1.3.1 Wrapper-Klasse Wie bereits erwähnt, stellt die Klasse mit dem Namen: com.privasphere.astf.plugin. ASTFPlugin nützliche Funktionen bereit, die von den pluginspezifischen Wrapper-Klassen geerbt werden können (siehe Abbildung 1.2). Da die run Methode abstrakt definiert wurde, muss diese Methode als einzige überschrieben werden, um ein neues Plugin anzusprechen. Durch den Abstraktionslayer mit der ASTFPlugin Klasse, wird der Zugriff auf die Plugins vereinheitlicht und sauber modeliert. Abbildung 1.2: ASTF Plugin Wrapper-Klasse Um ein Plugin vollends in das ASTF Framework zu integrieren, sind noch zwei ML Dateien mit Konfigurationsanweisungen zu erstellen. Weitere Details zur Konfiguration und Ausführung von Plugins können in der technischen Dokumentation des ASTF Frameworks nachgelesen werden (siehe [ASTF, 2008]). Kapitel 1. Einleitung 3

10 KAPITEL 2 Technische Details zu Web Vulnerability Scanner Dieses Kapitel soll eine Einführung in die Funktionsweise von heute aktuellen Web Vulnerability Scanner geben. Ein Schwerpunkt liegt in der Technik, welche die Scanner verwenden, um Schwachstellen in Webapplikationen aufzudecken. 2.1 Übersicht Auf fachbezogenen Webseiten wie SecurityFocus 1 und SecTools 2 findet man eine Vielzahl von verschiedenen Tools, welche die Sicherheit von Webseiten und Webservern überprüfen. Dabei variiert der Fokus dieser Applikationen stark. Grundsätzlich können diese aber in fünf Kategorien eingeteilt werden: 1. Scanner, die den Webserver auf Schwachstellen überprüfen 2. Scanner, die eine Webapplikation auf Cross-Site Scripting überprüfen 3. Scanner, die eine Webapplikation auf SQL Injection überprüfen 4. Tools, die via ein Proxy-Modul manuell Daten über eine Webapplikation sammeln 5. Frameworks, die alle oben genannten Punkte vereinen Nicht nur der Fokus, sondern auch die Qualität der Tools variiert stark. Obwohl kommerzielle Produkte sicherlich qualitativ hochwertig sind, fehlt ihnen der automatisierte Aspekt, der die Integration in das ASTF Framework erlaubt. Die Scanner, welche sich via Proxy zwischen den Browser und der Webapplikation befinden, können nicht genügend automatisiert werden, als dass sie für die Integration in das ASTF Framework in Frage kommen würden. Diese Art von Scanner erwartet, dass ein Benutzer 1 [ ] 2 [ ] Kapitel 2. Technische Details zu Web Vulnerability Scanner 4

11 die Webseite verwendet und der Scanner sammelt dabei die benötigten Daten um nach Schwachstellen zu suchen. Weiter muss erwähnt werden, dass es auch Tools gibt, die zusätzlich zu SQL Injections und SS Schwachstellen auch nach Cross-Site Request Forgery Schwachstellen suchen. 2.2 Fuzz Testing Scanner, welche in die Kategorie 2 und 3 fallen, verwenden meist alle dieselbe Technik, um Schwachstellen in Webapplikationen aufzudecken. Die Technik wird im Fachjargon Fuzz Testing genannt. Dabei werden Eingabefelder von HTML Formularen mit Daten gefüttert. Nach Absenden der Daten analysiert der Scanner das Verhalten der Applikation. Stürzt diese ab oder liefert Fehlermeldungen, so ist dies ein Zeichen, dass die Applikation eine Schwachstelle besitzt, wobei Scanner meist eine vorgefertigte Liste mit funktionierenden SQL- oder JavaScript Befehlen verwenden, um die Applikation auf Schwachstellen zu untersuchen (siehe Listing 2.1). Die Fuzz Testing Technik kann auf jede beliebige Applikation angewendet werden, die eine Art von Benutzereingabe erwartet. Der grosse Nachteil von Fuzz Testing besteht darin, dass nur simple Schwachstellen aufgedeckt werden können. Versteckt eine Applikation jegliche Fehlermeldungen vor dem Benutzer, so hat ein Scanner kaum eine Möglichkeit festzustellen, ob die Seite verwundbar ist. Allenfalls können die vom Webserver gesendeten HTML-Replies als Indiz für eine Schwachstelle verwendet werden. Fuzzer können nur einen Bruchteil der Applikation testen. Für bessere und genauere Tests müssen vorher definierte Testfälle verwendet werden. 1 POST / vuln / s q l / index. php HTTP/ 1. 1 userid=<script>a l e r t 2 ( Bn3khyi1DLRVlD1e)</SCRIPT> 2 POST / vuln / s q l / index. php HTTP/ 1. 1 userid =52" OR "52"="52 3 POST / vuln / s q l / index. php HTTP/ 1. 1 userid =52" AND "52"="53 4 POST / vuln / s q l / index. php HTTP/ 1. 1 userid =52 OR 52 = 52 5 POST / vuln / s q l / index. php HTTP/ 1. 1 userid =52 AND 52 = 53 6 POST / vuln / s q l / index. php HTTP/ 1. 1 userid=52 OR 52=52 7 POST / vuln / s q l / index. php HTTP/ 1. 1 userid=52 AND 52=53 8 POST / vuln / s q l / index. php HTTP/ 1. 1 userid=d z "0 Listing 2.1: Generierter HTTP Traffic eines Vulnerability Scanners 2.3 Webcrawler Manche Scanner kombinieren das Fuzz Testing zusätzlich mit einem Webcrawler. Dies automatisiert die Erkennung von Schwachstellen weiter. Webcrawler sind in der Lage, Strukturen von Webapplikationen zu analysieren. Sie verfolgen dabei Hyperlinks, welche sie auf einem zuvor konfigurierten Startpunkt finden. Die eingesetzten Webcrawler sind für das Auffinden von HTML Formularen optimiert. Die gefundenen Formulare können anschliessend mittels dem Fuzz Testing überprüft werden. Abbildung 2.1 Kapitel 2. Technische Details zu Web Vulnerability Scanner 5

12 zeigt wie typische Web Vulnerability Scanner funktionieren und wie sie die beiden oben genannten Techniken einsetzen. Abbildung 2.1: Typische Funktionsweise eines Web Vulnerability Scanners Die Limiten von automatisierten Webcrawlern liegen im sogenannten Deep-Web 3. Als Deep-Web werden diejenigen Webseiten bezeichnet, die erst durch eine Anfrage dynamisch aus Datenbanken generiert werden. Dadurch kann ein Crawler nie alle möglichen Seiten analysieren. Zusätzlich gibt es Bereiche, die durch eine Loginmaske geschützt sind. Ohne Konfiguration können die Scanner diesen Schutzmechanismus nicht überwinden. 2.4 Detektierung von Schwachstellen Scanner verwenden zwei Methoden, um Schwachstellen zu erkennen. Zum einen untersuchen sie die Antwort des Webservers nachdem dieser ein HTML Formular verarbeitet hat. Zum anderen können sie die HTML Status Codes untersuchen, um Abweichungen vom üblichen Verhalten festzustellen. Untersucht ein Scanner die Antwort des Servers, so sucht dieser meist nach bekannten Stichwörtern. Dazu gehören Standard-Fehler-Meldungen der verwendeten Datenbank. Verwendet man MySQL kann solch eine Fehlermeldung wie folgt lauten: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near at line 1 Werden HTML Status Codes verwendet, so kann ein Scanner unterscheiden, ob sich der Status Code der Server Antwort seit dem letzten Aufruf verändert hat Auch Hidden- oder Invisible Web genannt. 4 siehe RFC 2616 für eine Liste von möglichen HTTP Status Codes Kapitel 2. Technische Details zu Web Vulnerability Scanner 6

13 KAPITEL 3 Evaluation Dieses Kapitel beinhaltet die Evaluation verschiedener Web Vulnerability Scanner. In einem ersten Schritt sollen die wichtigsten Kriterien hervorgehoben werden, die bei der Evaluierung einer Applikation von Bedeutung sind. In einem weiteren Schritt wird die Versuchsanordnung erläutert, die verwendet wurde, um die Scanner zu testen. Anschliessend wird auf jede getestete Applikation ausführlich eingegangen. 3.1 Bewertungskriterien Auf folgende Kriterien wurde bei der Evaluierung geachtet. Umfang der Features Erkennungsrate von Schwachstellen Integrationsaufwand Automatisierung des Audits Kosten 3.2 Vorgehensweise Um mögliche Applikationen für die Evaluation zu finden, wurde hauptsächlich das Internet verwendet. Folgende Webseiten besitzen eine Liste von Web Vulnerability Scanner: Kapitel 3. Evaluation 7

14 Versuchsanordnung Die Versuchsanordnung umfasst mehrere Testfälle. Testfälle mit dem Namen xx_test_1.php erlauben die Ausführung von böswilligem JavaScript- und SQL-Code. Testfälle mit dem Namen xx_test _2.php schützen sich mittels Open Source Bibliotheken gegen diese Code Injection Attacken. Dazu gehört SafeSQL 1 und Inputfilter 2. Die Testfälle im Ordner bsql unterdrücken jegliche Fehlermeldungen, darum handelt es sich bei diesen Fällen um Blind-SQL Injection Schwachstellen. Zusätzlich existiert ein geschützter Bereich login/, der mittels einem Anmeldeformular betreten werden kann. Im geschützen Bereich befinden sich die gleichen Testfälle wie im ungeschützten Bereich. Die Scanner sollen anhand dieser Testfälle miteinander verglichen werden. Die Versuchsanordnung verwendet PHP 5 und MySQL Dateistruktur /vuln sql...sql Injection Test sql_test_1.php sql_test_2.php bsql... Blind-SQL Injection Test bsql_test_1.php bsql_test_2.php xss... SS Test xss_test_1.php xss_test_2.php login...login secured content sql...sql Injection Test sql_test_1.php sql_test_2.php bsql... Blind-SQL Injection Test bsql_test_1.php bsql_test_2.php xss... SS Test xss_test_1.php xss_test_2.php index.php... Login Sitemap index.php...sitemap Abbildung 3.1: Dateistruktur der Versuchsanordnung 1 [ ] 2 [ ] Kapitel 3. Evaluation 8

15 3.3.2 Cross-Site Scripting (SS) Listing 3.1 zeigt den SS Testfall Nummer 1 mit einer SS Schwachstelle. Der Code auf Zeile 3 gibt die Benutzereingaben ohne Überprüfung aus. Dies ermöglicht, fremden JavaScript Code auf der Seite einzubetten. 1 <?php 2 i f ( i s s e t ( $_POST [ value ] ) ) { 3 echo $_POST [ value ]. "<br / >"; 4 } 5?> 6 <!DOCTYPE HTML PUBLIC " //W3C//DTD HTML //EN" " http : / /www. w3. org /TR/ html4/ s t r i c t. dtd"> 7 <html> 8 <head> 9 < t i t l e >SS & SQL I n j e c t i o n Test </ t i t l e > 10 </head> 11 <body> 12 <form method="post " action="index. php" name="xssform"> 13 <input type=" t e x t " name="value " /> 14 <input type="submit " /> 15 </form> 16 </body> 17 </html> Listing 3.1: xss_test_1.php SQL Injection Listing 3.2 zeigt den SQL Injection Testfall Nummer 1. Der Code auf Zeile 6 übernimmt Benutzeringaben ohne Überprüfing in das SQL Query, welches anschliessend an die Datenbank übermittelt wird. Somit kann fremder SQL Code eingebettet werden. 1 <?php 2 i f ( i s s e t ( $_POST [ userid ] ) ) { 3 $ l i n k = mysql_connect ( l o c a l h o s t, vuln, mszsrjfpybm3munt ) ; 4 i f (! $ l i n k ) { die ( mysql_error ( ) ) ; } 5 mysql_select_db ( vuln, $ l i n k ) ; 6 $query = "SELECT username FROM user WHERE userid = ". $_POST [ userid ]. " " ; 7 $ r e s u l t = mysql_query ( $query ) ; 8 i f (! $ r e s u l t ) { die ( mysql_error ( ) ) ; } 9 } 10?> 11 <!DOCTYPE HTML PUBLIC " //W3C//DTD HTML //EN" " http : / /www. w3. org /TR/ html4/ s t r i c t. dtd"> 12 <html> 13 <head> 14 < t i t l e >SS & SQL I n j e c t i o n Test </ t i t l e > 15 </head> 16 <body> 17 <form method="post " action="index. php" name="sqlform"> 18 Enter UserId : <input type=" t e x t " name=" userid " /> Kapitel 3. Evaluation 9

16 19 <input type="submit " /> 20 </form> 21 <?php 22 i f ( i s s e t ( $_POST [ userid ] ) { 23 while ( $row = mysql_fetch_array ( $ r e s u l t ) ) { 24 echo "Username : ". $row [ 0 ] ; echo "<br / >"; 25 } 26 mysql_close ( $ l i n k ) ; 27 } 28?> 29 </body> 30 </html> Listing 3.2: sql_test_1.php Auf den nachfolgenden Seiten werden die einzelnen Tools genauer beschrieben. Die Resultate zu den einzelnen Tools befinden sich im Abschnitt Blind-SQL Injection Bei den Blind-SQL Injection Testfällen handelt es sich um die gleichen Testfälle wie bei den normalen SQL Injection Testfällen. Der einzige Unterschied besteht darin, dass die Fehlermeldungen unterdrückt werden. Kapitel 3. Evaluation 10

17 3.4 wapiti OS: Independent Open Source: Yes Language: Python Version: BETA Focus: SQL Injection & SS URL: Last Release: ASTF integration possible: Yes Beschreibung Wapiti allows you to audit the security of your web applications. It performs black-box scans, i.e. it does not study the source code of the application but will scans the webpages of the deployed webapp, looking for scripts and forms where it can inject data. Once it gets this list, Wapiti acts like a fuzzer, injecting payloads to see if a script is vulnerable. 3 Wapiti ist ein sehr ausgereiftes Tool, welches über einen internen WebCrawler verfügt. Wapiti braucht lediglich eine Start-URL, um die Applikation anschliessend zu testen. Report: Nach Abschluss des Audits erstellt Wapiti einen Report im ML sowie im HTML Format. Login: Damit Wapiti Zugriff auf den geschützten Bereich der Applikation erhält, der durch ein Anmeldeformular gesichert ist, existiert ein zusätzliches Script. Das Script erlaubt es, nach erfolgreicher Benutzerauthentifizierung das vom Webserver gesendete Cookie in eine Text-Datei abzulegen. Das gespeicherte Cookie kann beim tatsächlichen Scan durch einen Kommandozeilen-Parameter übergeben werden. Wapiti erhält somit Zugriff auf den geschützen Bereich. Listing 3.3 verdeutlicht die Anwendung dieses Scripts. Dabei werden die erhaltenen Cookie Informationen in die cookie.txt Datei gespeichert. 1 cmd:> python getcookie. py cookie. t x t http : / / l o c a l h o s t / vuln / l o g i n / index. php 2 Please enter values f o r the f o l l i n g form : 3 u r l = http : / / l o c a l h o s t / vuln / l o g i n / index. php 4 username ( on ) : admin 5 password ( on ) : admin 6 send ( SignOn ) : 7 0 : <Cookie PHPSESSID=e826ee94ba273b93b9a1b94eb51ab2a9 f o r l o c a l h o s t. l o c a l /> Listing 3.3: Wapiti Tool um Session Cookies zu speichern SSL: Den Zugriff auf die Testcases via SSL meisterte Wapiti erfolgreich und lieferte dieselben Ergebnisse wie ohne SSL. 3 [ ] Kapitel 3. Evaluation 11

18 3.5 w3af OS: Independent Open Source: Yes Language: Python Version: beta 7 Focus: Audit & Explotation Framework URL: Last Release: ASTF integration possible: Yes Beschreibung w3af is a Web Application Attack and Audit Framework. The project goal is to create a framework to find and exploit web application vulnerabilities that is easy to use and extend. 4 w3af wird als Metasploit 5 für Webapplikationen beschrieben. w3af besitzt über 130 Plugins, welche eine Applikationen auf Herz und Nieren überprüfen. Dazu gehören Plugins wie die Erkennung von Webserver Schwachstellen mittels Nikto, SS und SQL Injection Plugins. Report: Nach Abschluss des Audits erstellt w3af einen Report im HTML Format. Login: w3af verwendet ein Proxy-Plugin, um Cookies für den geschützten Bereich einer Applikation abzufangen. Dies würde normalerweise die Interaktion eines Benutzers voraussetzen. Mittels curl 6 kann dies aber weiter automatisiert werden. Listing 3.4 verdeutlicht die Anwendung von curl. Dabei werden die zu sendenen POST-Daten über den -F Parameter spezifiziert. 1 cmd:> c u r l. exe F "username=admin&password=admin" proxy : http : / / l o c a l h o s t / vuln / l o g i n / index. php 3 cmd:> c u r l. exe proxy : http : / / / spiderman? terminate Listing 3.4: w3af Automatisierung SSL: Den Zugriff auf die Testcases via SSL meisterte w3af erfolgreich und lieferte dieselben Ergebnisse wie ohne SSL. 4 [ ] 5 [ ] 6 curl is a command line tool for transferring files with URL syntax - [ ] Kapitel 3. Evaluation 12

19 3.6 sqlmap OS: Independent Open Source: Yes Language: Python Version: Focus: Known SQL Injection Bug Explotation URL: Last Release: ASTF integration possible: Yes (with configuration) Beschreibung sqlmap is an automatic SQL injection tool developed in Python. Its goal is to detect and take advantage of SQL injection vulnerabilities on web applications. Once it detects one or more SQL injections on the target host, the user can choose among a variety of options to perform an extensive back-end database management system fingerprint, retrieve DBMS session user and database, enumerate users, password hashes, privileges, databases, dump entire or user s specific DBMS tables/columns, run his own SQL SELECT statement, read specific files on the file system and much more. 7 sqlmap gehört nicht zu der Kategorie von Scannern, die einen WebCrawler besitzen. Deswegen ist sqlmap nicht in der Lage, eine Applikation automatisiert nach SQL-Injection Schwachstellen abzusuchen. Jedoch liegen die Stärken von sqlmap in der Detektierung von Blind-SQL Injection Schwachstellen, sobald ein Benutzer genügend Informationen liefert. 1 cmd:>sqlmap current db t a b l e s D vuln method POST data=" userid =1" 2 u http : / / l o c a l h o s t / vuln / bsql / index. php 3 back end DBMS: MySQL >= current database : vuln 5 Database : vuln 6 [2 t a b l e s ] products 9 user Listing 3.5: Funktionsweise von sqlmap 7 [ ] Kapitel 3. Evaluation 13

20 3.7 Paros Proxy OS: Independent Open Source: Yes Language: Java Version: Focus: Web Application Assessment URL: Last Release: ASTF integration possible: Yes Beschreibung We wrote a program called "Paros"for people who need to evaluate the security of their web applications. It is free of charge and completely written in Java. Through Paros s proxy nature, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified. 8 Paros ist als Proxy konzipiert, wobei gewisse Funktionen auch über die Kommando-Zeile ausgeführt werden können, dazu gehört auch eine WebCrawler Komponente, welche der Automatisierung der Scans dient. Report: Nach Abschluss des Audits erstellt Paros einen Report im HTML Format. Login: Den geschützen Bereich der Testfälle konnte Paros nur durch manuelles ausfüllen der Loginmaske erreichen. Die Ausführung über die Kommando-Zeile stellt nicht genügend Parameter zur Verfügung, um eine Session-ID bzw. Cookie mitzugeben. 1 cmd:> j a v a j a r paros. j a r newsession t e s t. session spider 2 seed http : / / l o c a l h o s t / vuln / index. php scan l a s t _ s c a n _ r e p o r t report Listing 3.6: Funktionsweise von paros 8 [ ] Kapitel 3. Evaluation 14

21 3.8 OWASP WebScarab OS: Independent Open Source: Yes Language: Java Version: Focus: Web Application Assessment URL: Last Release: ASTF integration possible: No Beschreibung WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab. 9 WebScarab ist ein sehr ausgereiftes OpenSource Produkt mit vielen Features. Was WebScarab hingegen fehlt ist eine automatisierte Scan-Funktion, die über die Kommandozeile gestartet werden kann. Aus diesem Grund kann WebScarab nicht in das ASTF Framework integriert werden. 9 [ ] Kapitel 3. Evaluation 15

22 3.9 Grendel-Scan OS: Independent Open Source: Yes Language: Java Version: 1.0 Focus: Web Application Assessment URL: Last Release: ASTF integration possible: Yes (Version >= 1.1) Beschreibung Grendel-Scan is an open-source web application security testing tool. It has automated testing module for detecting common web application vulnerabilities, and features geared at aiding manual penetration tests. The only system requirement is Java 5; Windows, Linux and Macintosh builds are available. 10 Zur Zeit besitzt Grendel-Scan keine automatisierte Scan-Funktion. Aus dem aktuellen ChangeLog geht aber hervor, dass ab Version 1.1 ein solches Feature implementiert wird. Ab dem nächsten Release würde sich Grendel-Scan als Kandidat für die Integration in das ASTF Framework qualifizieren. Die Funktionen von Grendel-Scan umfassen einen Webcrawler, SQL Injection- und SS detection Module. Zudem existieren weitere Module für die Erkennung von CRLF Injection und CSRF Injection Schwachstellen. Wobei die Konfiguration umständlich und die Resultate je nach Konfiguration stark variieren. Grendel-Scan sieht vielversprechend aus, bedarf aber noch einiges an Entwicklungsaufwand. Report: Nach Abschluss des Audits erstellt Grendel-Scan einen Report im HTML Format. Login: Wie Grendel-Scan in den geschützen Bereich gelangt, kann über die Einstellungen konfiguriert werden. Die Einstellungen können in einer Text-Datei abgelegt und wieder verwendet werden. SSL: Grendel-Scan kann Verbindungen via SSL aufbauen [ ] Kapitel 3. Evaluation 16

23 3.10 Burp-Suite OS: Independent Open Source: No (Demo-Edition: 0 / Pro-Edition: 99 Language: Java Version: 1.1 Focus: Web Application Assessment URL: Last Release: ASTF integration possible: No Beschreibung Burp Suite is an integrated platform for attacking web applications. It contains all of the Burp tools with numerous interfaces between them designed to facilitate and speed up the process of attacking an application. All tools share the same robust framework for handling HTTP requests, authentication, downstream proxies, logging, alerting and extensibility. Burp Suite allows you to combine manual and automated techniques to enumerate, analyse, attack and exploit web applications. The various Burp tools work together effectively to share information and allow findings identified within one tool to form the basis of an attack using another. 11 Das Konzept von Burp ist dasselbe wie das von WebScarab. Wie auch WebScarab besitzt Burp keine automatisierte Scan-Funktion. Die Integration in das ASTF Framework ist somit nicht möglich. Zusätzlich ist die Free-Version von Burp mit einer Demo-Version des Burp-Intruders ausgestattet, wobei es sich hier um die Fuzz-Testing Komponente der Suite handelt [ ] Kapitel 3. Evaluation 17