Wie testet man eine Web-Anwendung auf Schwachstellen?
Eine Web-Anwendung testet man, indem man prüft, was sie mit Eingaben macht, die ihr Entwickler nicht vorgesehen hat. Die häufigsten Schwachstellen sind SQL-Injection, Cross-Site-Scripting und die Umgehung von Pfaden.
Du lernst, solche Anfragen zu erkennen und einzuordnen. Du testest nur deine eigene Kopie und nur mit Erlaubnis.
Am Ende dieser Lektion
Notiz
Ich kann eine Anfrage an eine Web-Anwendung als normal oder als Angriffsversuch einordnen.
Schlüsselwörter
| Begriff | Was er bedeutet | Beispiel |
|---|---|---|
| Schwachstelle | ein Fehler, den ein Angreifer ausnutzen kann | |
| Parameter | ein Wert, den die Adresse an die Anwendung übergibt | id=7 |
| SQL-Injection | Eingabe, die zum Teil einer Datenbankabfrage wird | |
| Cross-Site-Scripting | Eingabe, die als Code in einer fremden Seite läuft | |
| Pfadumgehung | ein Zugriff auf Dateien außerhalb des erlaubten Ordners |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Wie ist eine Anfrage an eine Web-Anwendung aufgebaut?
Dein Browser schickt bei jedem Klick eine Anfrage. Sie enthält die Art (zum Beispiel GET), den Pfad der Seite und danach hinter einem Fragezeichen die Parameter.
Parameter sind Eingaben, die die Anwendung weiterverarbeitet, etwa die Nummer eines Produkts oder dein Suchwort. Bei Schwachstellen kommt es auf genau diese Eingaben an.
Beispiel: eine erfundene Anfrage in ihren Teilen
| Teil | Beispiel | Was er ist |
|---|---|---|
| Art | GET | Die Seite wird geholt |
| Pfad | /produkt | Welche Seite gemeint ist |
| Parameter | id=7 | Die Eingabe: Produkt Nummer 7 |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Die eine Regel für dieses Lab
Warnung
Teste nur deine eigene Kopie des Labs und nie eine fremde Web-Anwendung ohne schriftliche Erlaubnis. Das wäre strafbar, auch wenn du es „nur testen“ willst. Du lernst, Angriffe zu erkennen, damit du Anwendungen sicherer machst.
Bevor du anfängst
Notiz
Drück oben in der Leiste auf Lab starten und warte, bis es läuft. Mit Öffnen siehst du die Anwendung DVWA. Die Befehle erscheinen im Terminal, wenn du auf Ausführen drückst.
Antwortet die Anmeldeseite?
curl -s -o /dev/null -w '%{http_code}\n' http://dvwa/login.phpHier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Was antwortet eine Seite, die es nicht gibt?
curl -s -o /dev/null -w '%{http_code}\n' http://dvwa/gibt-es-nichtHier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Welche drei Schwachstellen kommen am häufigsten vor?
Bei der SQL-Injection wird eine Eingabe Teil einer Datenbankabfrage. Typisch ist ein Hochkomma mit OR darin, das die Abfrage verändert.
Beim Cross-Site-Scripting (XSS) wird eine Eingabe als Code in die Seite eingebaut, zum Beispiel ein script-Tag. Bei der Pfadumgehung versucht jemand mit ../, aus dem erlaubten Ordner hinauszukommen.
Woran man die drei Schwachstellen erkennt
| Schwachstelle | Typisches Zeichen in der Eingabe | Gegenmittel der Entwickler |
|---|---|---|
| SQL-Injection | Ein Hochkomma, dann OR oder UNION SELECT | Abfragen mit Platzhaltern bauen |
| Cross-Site-Scripting | Ein script-Tag oder onerror= | Eingaben beim Anzeigen maskieren |
| Pfadumgehung | Die Folge ../ | Dateinamen prüfen und nur erlaubte Ordner nutzen |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Ein häufiger Fehler
Warnung
Viele denken, es genüge, wenn die Webseite Eingaben prüft, denn Buchstaben im Zahlenfeld lässt der Browser gar nicht zu. Ein Angreifer schickt die Anfrage aber ohne Browser. Darum muss immer der Server jede Eingabe prüfen.
Wie geht man beim Testen vor?
Man ändert immer nur eine Sache, schaut, was die Anwendung antwortet, und schreibt Anfrage und Antwort auf. So kann man jeden Fund später erklären.
DVWA hat dazu einen Sicherheitsgrad. Auf niedrig ist eine Übung leicht, auf hoch ist die Lücke geschlossen. Vergleichen zeigt, was der Code dort anders macht.
Weiterführend: ein Protokoll lesen
In der letzten Lektion hast du Protokolle gelesen. Ein Webserver schreibt jede Anfrage in sein Protokoll. Stell dir vor, du siehst dort 20 Zeilen mit ../ von derselben Adresse.
Welche Schritte aus der Reaktion auf Vorfälle würdest du als Erstes gehen?