Laborversuche zu den OWASP Top Ten mit OWASP WebGoat
Das „Open Web Application Projekt“ (OWASP) beschreibt auf einer umfangreichen Website häufige Angriffe auf Web Applikationen und stellt eine Top-Ten Liste zu den häufigsten Angriffen zusammen. OWASP listet die folgenden Schwachstellen in Web Applikationen auf, die als besonders kritisch angesehen werden:
Die Reihenfolge der Auflistung ist dabei relevant. Um die üblichen Sicherheitslücken in eigenen Versuchen zu erproben bietet OWASP die Applikation WebGoat an (https://github.com/WebGoat/WebGoat). Dies ist eine von OWASP entwickelte Versuchsumgebung, mit der bekannte Web-Attacken ausprobiert werden können.
OWASP WebGoat enthält mehrere Kurse und Lektionen aus verschiedenen Bereichen der OWASP Top Ten. Die Applikation enthält zu jeder Aufgabe auch Hinweise (Hints) und einen kompletten Lösungsweg. Meistens existieren mehrere Lösungsmöglichkeiten der Aufgabe. In den Versuchsbeschreibungen zu den Lektionen ist angegeben, ob Hinweise oder der komplette Lösungsweg verwendet wurde.
Um die Versuchsumgebung einfach zu halten, wurde die WebGoat Applikation auf einem Windows 8 System installiert. Dieses System dient in den nachfolgenden Versuchen sowohl als Client-, wie auch als Serversystem.
Die Installation von WebGoat ist denkbar einfach, ein ZIP-File kann von http://code.google.com/p/webgoat/downloads/list heruntergeladen werden und enthält alle benötigten Dateien für die Testumgebung. Nach dem Ausführen der Datei webgoat.bat steht ein Webserver auf Basis von Tomcat und Java unter der URL: http://localhost/WebGoat/attack zur Verfügung. Nach einem Login (Benutzername: guest, Passwort: guest) stehen dem Benutzer mehrere Kurse und Lektionen zur Auswahl.
Es wird noch ein weiteres Tool benötigt. Der von OWASP Entwickelte Zed Attack Proxy (ZAP - https://github.com/zaproxy/zaproxy/). ZAP ist ein lokaler Proxy Server. Die Anfragen des Browsers werden über ZAP zur Web Applikation weitergeleitet. Eine nützliche Funktion von ZAP ist, dass im Programm Breakpoints gesetzt werden können. Wenn zum Beispiel ein Breakpoint für www.nzz.ch gesetzt wird, und der Browser über den ZAP Proxy auf diese Website zugreifen will stoppt ZAP den Zugriff und bietet dem Benutzer die Möglichkeit, die Parameter des Zugriffs zu verändern.
Um also z.B. die Post oder Form- Parameter einer Seite zu manipulieren, werden die Browser Anfragen manipuliert:
Der Browser enthält dann die Antwort auf diesen manipulierten Request vom ZAP Proxy.
Die Seite der Lektion zeigt ein einfaches Formular für Wetterdaten, in dem über ein Drop-Down Menu eine Stadt ausgewählt werden kann. Mit einem Klick auf „Go!“ werden die Wetterdaten für diese Stadt und das ausgeführte SQL-Statement ausgegeben.
Das Ziel der Lektion ist, den Form Parameter station so
zu manipulieren, dass die gesamte Tabelle weather_data
angezeigt wird.
Dazu wird mit dem ZAP Proxy der Original Post-Request auf die Seite:
POST http://localhost/WebGoat/attack?Screen=77&menu=1100 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://localhost/WebGoat/attack?Screen=77&menu=1100
Cookie: JSESSIONID=9BBB822B1EF34454C076748E53489244
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
station=102&SUBMIT=Go%21abgefangen und der station Parameter folgendermassen
modifiziert:
station=102 OR 1=1&SUBMIT=Go%21Nun liefert der Webserver dem Benutzer als Antwort die ganze Tabelle der Wetterdaten.
In dieser Lektion geht es darum, den Request auf einen Lektionen Plan so zu modifizieren, dass ein Betriebssystem Kommando ausgeführt wird.
Um ein Betriebssystem Kommando auszuführen wir der Post Request modifiziert:
POST http://localhost/WebGoat/attack?Screen=87&menu=1100 HTTP/1.1
Host: localhost
Proxy-Connection: keep-alive
Content-Length: 45
Cache-Control: max-age=0
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost/WebGoat/attack?Screen=87&menu=1100
Accept-Encoding: sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: JSESSIONID=9CC0B024D1C14A14120BE7F92AA39BFD
HelpFile=AccessControlMatrix.help&SUBMIn der letzten Zeile wird nun der Form Parameter erweitert und folgendermassen an den Webserver geschickt:
HelpFile=AccessControlMatrix.help"%26%26 echo "test"&SUBMIT=View"Dazu sind ein paar Erklärungen nötig:
%26 ist die codierte Version des
UND-Zeichens &.&& können in der Windows Command
Shell (cmd) Befehle nacheinander ausgeführt werden.Der Befehl, welcher als String an das cmd.exe File des Webservers übergeben wird, lautet also:
cmd.exe /c type "C:\Users\osc\Desktop\WebGoat\WebGoat-5.4-OWASP_Standard_Win32\WebGoat-5.4\tomcat
\webapps\WebGoat\lesson_plans\English\AccessControlMatrix.html"&& echo "test"Er enthält neben dem eigentlichen Befehl, die Hilfedatei anzuzeigen,
auch noch einen weiteren echo Befehl, welcher „test“ auf
der Konsole ausgibt.
Das Ziel der Lektion Log Spoofing ist es, einen falschen
Eintrag im Log File des Servers zu erstellen, der so aussieht, als ob
sich der Benutzer admin erfolgreich eingeloggt hätte.
Lektionsziele
Um die Aufgabe zu erfüllen, musste auf die Hinweise zur Lektion „Hints“ zurückgegriffen werden. Die Hinweise lauteten folgendermassen:
%0d) and LF
(%0a) for a new line.Damit ist nun klar, wie das Ziel erreicht werden soll. Neben dem
ersten nicht erfolgreichen Log-Eintrag für den Login eines Benutzers
soll noch eine weitere Zeile mit dem erfolgreichen Login des Benutzers
admin angefügt werden. Dies konnte folgendermassen
ausgeführt werden:
Olivier%0d%0aLogin Succeeded for username: admin.Login failed for username: einfach noch den Benutzernamen
an. Da der Benutzername nun aber noch einen Zeilenumbruch und einen
weiteren Log Eintrag erhält, sieht die Log Datei anschliessend
folgendermassen aus:{.sourceCode .} Login failed for username: Olivier Login Succeeded for username: admin
In dieser Lektion soll ein „Denial of Service“ Angriff auf ein Loginformular ausgeführt werden. Gemäss der Aufgabenbeschreibung erlaubt die Seite mehrere Logins eines Benutzers. Die Seite hat dazu einen Database connection pool der 2 Verbindungen zulässt.
Um die Aufgabe zu lösen muss:
Ein Login mit dem Benutzernamen „oli“ und dem Passwort „oli“ zeigt, dass folgendes SQL Statement abgefragt wird, um den Benutzer zu identifizieren:
SELECT * FROM user_system_data WHERE user_name = 'oli' and password = 'oli'Das User Feld eignet sich für eine SQL Injection Attacke. Es müsste also möglich sein, das SQL Statement abzuändern und die Passwort-Abfrage zu umgehen.
Der ZAP Proxy liefert den Request auf die Seite:
POST http://localhost/WebGoat/attack?Screen=139&menu=1200 HTTP/1.1
…
Username=oli&Password=oli&SUBMIT=LoginEine kurze Internetrecherche zeigt, dass SQL Statements mit „–„ und nicht mit „;“ auskommentiert werden. Der zweite Versuch mit folgendem Post Parameter:
Username=oli' OR 1=1 --&Password=oli&SUBMIT=LoginLiefert eine Tabelle der Benutzer:
Mit den Login Angaben können nun mehrere Logins auf die Seite ausgeführt werden. Nach dem Login der Benutzer jsnow, jdoe, und jplane erscheint eine Meldung über den erfolgreichen Abschluss der Lektion von OWASP WebGoat.
OWASP WebGoat erlaubt es interessierten Personen ohne grossen Aufwand bekannte Attacken auf Web Applikationen auf einfache Weise nachzustellen. Die ausgeführten Versuche waren vom Schwierigkeitsgrad her nicht besonders hoch, weisen aber einen hohen Lerneffekt durch „Learning by doing“ auf. Zudem stellen sich rasch Erfolgserlebnisse ein, so dass die Arbeit mit den Lektionen Spass macht. Die in meinem Versuch verwendete Versuchsumgebung könnte ohne grossen Aufwand in der Laborumgebung der HSLU installiert werden und so weiteren Studenten zur Verfügung stehen.