SQL- und Command-Injection

Zwei klassische Injection-Schwachstellen im Vergleich: Benutzereingaben, die ungeprüft in eine Datenbankabfrage bzw. einen Shell-Befehl eingebaut werden. Demo starten und Schritt für Schritt verfolgen, wie aus einer harmlosen Eingabe ein manipulierter Befehl wird.

Eine Suchfunktion nimmt einen Benutzernamen entgegen und baut daraus per String-Konkatenation eine SQL-Abfrage. Wird die Eingabe nicht escaped oder als Parameter gebunden, kann ein Angreifer die Struktur der Abfrage selbst verändern — statt eines Namens einen Teil der WHERE-Bedingung.

Anwendungsserver (1) HTTP Request (2) SQL Query (3) Ergebnis (4) Antwort Client Benutzersuche Webserver baut Query per String Datenbank MySQL
Demo auswählen, um den Ablauf zu starten.

Eingabe — das tippt der Nutzer ins Suchfeld

Benutzername
wird beim Start der Demo befüllt …
↓ wird 1:1 in die Abfrage eingesetzt

Tatsächlich ausgeführte Query — das sieht die Datenbank

// erscheint hier
idusernamerolle

Warum funktioniert das

Gegenmaßnahme

Eine Web-Anwendung nimmt einen Hostnamen entgegen und ruft im Hintergrund ping über eine Shell auf, um die Erreichbarkeit zu prüfen. Wird die Eingabe direkt in den Shell-Befehl eingesetzt, kann ein Angreifer über Shell-Metazeichen zusätzliche Befehle anhängen.

Anwendungsserver (1) HTTP Request (2) Shell-Aufruf (3) stdout (4) Antwort Client Ping-Check Webserver exec() / system() Shell /bin/sh
Demo auswählen, um den Ablauf zu starten.

Eingabe — das tippt der Nutzer ins Hostname-Feld

Host
wird beim Start der Demo befüllt …
↓ wird 1:1 in den Shell-Befehl eingesetzt

Tatsächlich ausgeführter Befehl — das sieht die Shell

// erscheint hier

Warum funktioniert das

Gegenmaßnahme