SQL / SECURITY

SQL-Injection 2024 – warum das immer noch passiert

SQL-Injection ist kein exotischer Angriff. Es ist einer der häufigsten und am leichtesten zu behebenden Schwachstellen in Webanwendungen. Trotzdem taucht sie 2024 immer noch regelmäßig auf – in Legacy-Code, in schnell hingeworfenen Projekten, manchmal sogar in Code von Leuten die es eigentlich besser wissen sollten.

Wie eine Lücke aussieht

Der klassische Fall: Nutzereingabe direkt in die SQL-Query eingebaut.

# Angenommen: URL ist /user?id=1 $query = "SELECT * FROM users WHERE id=" . $_GET['id']; # Was ein Angreifer eingibt: ?id=1 OR 1=1 # Ergebnis: SELECT * FROM users WHERE id=1 OR 1=1 # = alle User werden zurückgegeben # Schlimmer: ?id=1; DROP TABLE users; --

Warum es passiert

Der falsche Weg ist schneller zu tippen. String-Concatenation ist intuitiv für jeden der Programmieren gelernt hat. Der sichere Weg erfordert ein paar zusätzliche Zeilen die man vielleicht nicht sofort versteht. Und das Problem sieht man nicht – der Code funktioniert ja, für normale Eingaben.

Die Lösung: Prepared Statements

# So – Prepared Statement mit Parameter-Binding $stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id"); $stmt->execute([':id' => (int) $_GET['id']]); $user = $stmt->fetch(); # Der Wert wird nie als SQL interpretiert, nur als Daten # Egal was der Nutzer eingibt – kein SQL-Injection möglich

Das sind drei Zeilen statt einer. Der Unterschied in der Sicherheit ist fundamental. PDO macht das mit allen unterstützten Datenbanken, MySQLi ebenfalls für MySQL.

Es gibt keine Ausrede mehr für SQL-Injection in neuem Code. Die Tools sind da, die Dokumentation ist da, die Lösung ist klar. Einfach Prepared Statements benutzen. Immer.

← zurück zu Security 📂 Archiv