SQL-Injection und Command-Injection
Lernen Sie, wie Angreifer Injection-Payloads erstellen, die Datenbankabfragen oder Betriebssystembefehle manipulieren, und wie parametrisierte Abfragen und Eingabevalidierung dies verhindern.
SQL-Injection und Command-Injection ist eine kostenlose Security+ Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Security+ Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Was ist SQL Injection?
SQL Injection (SQLi) tritt auf, wenn ein Angreifer schädlichen SQL-Code in ein Eingabefeld einschleust, der später an eine Datenbankabfrage übergeben wird. Da die Anwendung Benutzereingaben direkt mit einem SQL-Statement verkettet, kann die Datenbank nicht zwischen legitimen Daten und vom Angreifer übergebenen Befehlen unterscheiden. SQLi zählt im OWASP Top 10 regelmäßig zu den gefährlichsten Web-Schwachstellen.
Beispiel für ein klassisches SQLi-Payload
Eine anfällige Login-Abfrage könnte folgendermaßen aussehen: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Gibt ein Angreifer ' OR '1'='1 als Benutzernamen ein, verändert sich die Abfrage so, dass die WHERE-Klausel immer wahr ist und die Authentifizierung vollständig umgangen wird. Dies ist die klassische tautologiebasierte Injection.
-- Vulnerable query (DO NOT use in production)
SELECT * FROM users
WHERE username = '' OR '1'='1'
AND password = 'anything';
-- Returns ALL rows — auth bypassedArten von SQL Injection
SQL-Injection-Angriffe treten in mehreren Formen auf: In-Band-SQLi gibt Ergebnisse direkt in der HTTP-Antwort zurück (fehlerbasiert oder union-basiert). Blind SQLi leitet Daten aus booleschen Wahr/Falsch-Antworten oder absichtlich erzeugten Zeitverzögerungen ab (SLEEP(5)). Out-of-Band-SQLi verwendet sekundäre Kanäle wie DNS-Abfragen, um Daten zu exfiltrieren, wenn die Antworten nicht sichtbar sind.
-- Time-based blind SQLi example
SELECT * FROM users
WHERE id = '1' AND SLEEP(5)--';
-- If response is delayed 5s, injection succeededSQLi verhindern: parametrisierte Abfragen
Die wichtigste Abwehrmaßnahme gegen SQL Injection sind parametrisierte Abfragen (auch Prepared Statements genannt). Bei einer parametrisierten Abfrage wird die SQL-Struktur zuerst kompiliert, und die Benutzereingabe wird als separater Parameter übergeben – sie kann die Abfragestruktur niemals verändern. Dieser Ansatz ist sprachunabhängig und wesentlich zuverlässiger als die alleinige Bereinigung von Eingaben.
# Python example — parameterized query (safe)
import sqlite3
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
username = 'admin'
password = 'secret'
cursor.execute(
'SELECT * FROM users WHERE username=? AND password=?',
(username, password) # parameters, never concatenated
)Eingabevalidierung als Defense in Depth
Parametrisierte Abfragen sind zwar die wichtigste Abwehrmaßnahme, doch Eingabevalidierung bietet eine wichtige zusätzliche Schutzschicht. Eine Allowlist-Validierung akzeptiert nur erwartete Zeichen (z. B. ausschließlich alphanumerische Zeichen in einem Benutzernamenfeld) und weist alle anderen zurück. Eine Denylist-Validierung blockiert bekannte schädliche Zeichen. Angreifer codieren oder verschleiern ihre Payloads jedoch häufig, um Denylists zu umgehen – Allowlists sind daher deutlich robuster.
Was ist Command Injection?
Command Injection (OS Command Injection) tritt auf, wenn eine Anwendung ungeprüfte Benutzereingaben an eine System-Shell übergibt. Im Gegensatz zu SQL Injection, die auf Datenbanken zielt, richtet sich Command Injection direkt gegen das Betriebssystem. Dadurch können Angreifer beliebige Befehle mit den Berechtigungen des Webserver-Prozesses ausführen. Die Schwachstelle wird als kritisch eingestuft und führt häufig zur vollständigen Kompromittierung des Systems.
Beispiel für Command Injection
Eine Webanwendung, die eine von einem Benutzer angegebene IP-Adresse anpingt, könnte Folgendes verwenden: ping -c 1 INPUT. Gibt ein Angreifer 8.8.8.8; cat /etc/passwd ein, interpretiert die Shell ; als Befehlsseparator und führt beide Befehle aus. Zu den üblichen Injection-Operatoren gehören ;, &&, ||, | und die Befehlsausführung durch Backticks.
# Vulnerable Python (subprocess with shell=True)
import subprocess
user_ip = '8.8.8.8; cat /etc/passwd' # attacker input
subprocess.run('ping -c 1 ' + user_ip, shell=True)
# Safe alternative — avoid shell=True, pass args as list
subprocess.run(['ping', '-c', '1', '8.8.8.8'])Command Injection verhindern
Die sicherste Abwehrmaßnahme gegen Command Injection besteht darin, OS-Befehle aus Benutzereingaben vollständig zu vermeiden und stattdessen Bibliotheksfunktionen zu verwenden, die dasselbe Ziel erreichen. Wenn Shell-Aufrufe unvermeidbar sind, übergeben Sie Argumente als Liste (niemals als verketteten String), deaktivieren Sie die Shell-Interpretation, validieren Sie Eingaben anhand einer strengen Allowlist und führen Sie Prozesse mit einem Benutzerkonto mit möglichst geringen Berechtigungen aus.
OWASP-Kontext: Injection in den Top 10
Die OWASP Top 10 führen Injection (einschließlich SQL-, NoSQL-, OS- und LDAP-Injection) als eines der kritischsten Anwendungssicherheitsrisiken auf. OWASP empfiehlt einen Defense-in-Depth-Ansatz: Verwenden Sie sichere APIs, die den Interpreter umgehen, führen Sie serverseitig eine positive Eingabevalidierung (Allowlist) durch, maskieren Sie Sonderzeichen mithilfe der für den jeweiligen Interpreter spezifischen Syntax und verwenden Sie SQL-Steuerungen wie LIMIT, um die massenhafte Offenlegung von Daten zu verhindern.
Erkennung: WAFs und Protokollierung
Eine Web Application Firewall (WAF) kann gängige Injection-Payloads erkennen und blockieren, indem sie HTTP-Anfragen anhand von Signaturmustern überprüft. WAFs können jedoch durch Kodierungstricks umgangen werden und sind kein Ersatz für sichere Programmierung. Eine ordnungsgemäße Protokollierung der Anwendung – einschließlich Abfrageparametern, Antwortcodes und Fehlermeldungen – ermöglicht es Sicherheitsteams, Injection-Versuche bei der Untersuchung von Sicherheitsvorfällen zu erkennen.
Auswirkungen von Injection-Angriffen in der Praxis
Injection-Angriffe haben einige der größten Datenpannen der Geschichte verursacht. Die Datenpanne bei Equifax im Jahr 2017 legte durch eine Schwachstelle in einer Webanwendung die Daten von 147 Millionen Datensätzen offen. Eine SQL-Injection gegen das Sony PlayStation Network kompromittierte 2011 insgesamt 77 Millionen Konten. Diese Vorfälle zeigen, dass Injection-Schwachstellen extreme geschäftliche Auswirkungen haben: Datendiebstahl, aufsichtsrechtliche Geldstrafen, Reputationsschäden und rechtliche Haftung sind allesamt mögliche Folgen eines erfolgreichen Injection-Angriffs.
Kurze Wissensüberprüfung
Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: SQL-Injection nutzt ungefilterte Eingaben aus, die in Datenbankabfragen verkettet werden, Command Injection schleust über Operatoren wie ; und | schädliche Eingaben in die Betriebssystem-Shell ein und parametrisierte Abfragen sowie der Verzicht auf shell=True sind die wichtigsten Schutzmaßnahmen. Als Nächstes befassen wir uns mit Cross-Site Scripting (XSS) und CSRF-Angriffen.
Häufig gestellte Fragen
Ist die Lektion „SQL-Injection und Command-Injection“ kostenlos?
Ja — der vollständige Text von „SQL-Injection und Command-Injection“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Security+ Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „SQL-Injection und Command-Injection“?
Lernen Sie, wie Angreifer Injection-Payloads erstellen, die Datenbankabfragen oder Betriebssystembefehle manipulieren, und wie parametrisierte Abfragen und Eingabevalidierung dies verhindern. Du übst Security+ Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Security+ Academy zu starten?
Keine Vorkenntnisse erforderlich. Security+ Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „SQL-Injection und Command-Injection“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Security+ Academy-Lektion Code schreiben und ausführen?
Ja. Jede Security+ Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- SQL-Injection und Command-Injection
- Cross-Site-Scripting (XSS) und CSRF
- Fehlerhafte Authentifizierung und unsichere Deserialisierung
- Sicherer SDLC, SAST- und DAST-Tools