Was ist SQL-Injection?

SQL-Injection: Definition und Ursache

Webanwendungen speichern Kunden, Bestellungen und Inhalte meist in einer SQL-Datenbank und fragen sie mit SQL-Befehlen ab. Entsteht ein solcher Befehl, indem Benutzereingaben einfach in den Text eingefügt werden, kann ein Angreifer die Struktur des Befehls verändern. Die Datenbank kann Code und Daten dann nicht mehr unterscheiden.

Die Ursache ist fast immer dieselbe: Eingaben aus Formularen, Suchfeldern, Cookies oder Adressparametern werden ungeprüft in Datenbankabfragen eingebaut. SQL-Injection zählt seit Jahren zur Kategorie „Injection“ der OWASP Top 10, obwohl die wirksame Gegenmaßnahme seit Langem bekannt ist. Betroffen sind vor allem ältere Individuallösungen und ungepflegte Plugins.

So funktioniert ein Angriff

Ein Angreifer trägt statt eines Suchbegriffs einen Textbaustein ein, der die ursprüngliche Abfrage verändert, etwa so, dass eine Bedingung immer wahr ist. Damit lassen sich Login-Prüfungen umgehen, Daten aus anderen Tabellen auslesen oder Einträge verändern, im Extremfall sogar löschen. Mit automatisierten Werkzeugen testen Angreifer tausende Seiten auf solche Schwächen; ungefiltert angezeigte Datenbank-Fehlermeldungen erleichtern ihnen die Arbeit.

• Datenabfluss: Kundendaten, Bestellungen oder Zugangsdaten werden ausgelesen
• Manipulation: Preise, Inhalte oder Konten werden verändert
• Umgehung: Anmeldungen werden ohne gültiges Passwort akzeptiert
• Im ungünstigen Fall: Übernahme des Datenbankservers oder weiterer Systeme

Praxis­bei­spiel: Der alte Shop-Filter

Ein Fachhändler betreibt einen Webshop auf Basis einer individuell programmierten Altlösung. Der Produktfilter baut die Datenbankabfrage direkt aus dem Adressparameter zusammen. Ein Angreifer ändert den Parameter und kann so Tabellen mit Kundendaten abrufen; der Händler bemerkt es erst, als Kunden Betrugsmails mit ihren echten Bestelldaten erhalten. Der Schaden: Vertrauensverlust, Aufwand und möglicherweise Meldepflichten.

Die Lösung ist handwerklich schlicht: Die Abfragen werden auf parametrisierte Statements umgestellt, die Datenbankrechte des Shops eingeschränkt und Fehlermeldungen nach außen verborgen. Eine Web Application Firewall bietet zusätzlichen Schutz, ersetzt die Korrektur im Code aber nicht. Nach dem Vorfall bleibt zu klären, welche Daten betroffen waren.

Schutz­maß­nahmen und Umsetzung

Wirksamster Schutz sind Prepared Statements (parametrisierte Abfragen), bei denen Befehl und Daten strikt getrennt bleiben. ORMs und moderne Frameworks nutzen sie standardmäßig, solange man keine Abfragen per Textverkettung baut. Ergänzend helfen Eingabevalidierung nach dem Positivprinzip, ein Datenbankbenutzer mit minimalen Rechten, aktuelle Software und gezielte Sicherheitstests.

Nano Concepts prüft Code und Konfigurationen mit Code-Reviews und Schwachstellenanalysen, behebt Lücken in bestehenden Anwendungen und entwickelt neue Software von Beginn an nach sicheren Standards. Bei älteren Individuallösungen empfiehlt sich oft eine schrittweise Modernisierung statt dauerhafter Notreparaturen, damit die Sicherheit nicht an einzelnen Stellen hängt.

• SQL durch Textverkettung aus Benutzereingaben zusammenbauen
• Datenbankbenutzer mit Administratorrechten für die Website einsetzen
• Detaillierte Datenbankfehler im Browser anzeigen
• Nur auf Eingabefilter („Sonderzeichen entfernen“) vertrauen
• Veraltete Plugins und Altskripte weiterbetreiben