Was ist eine SQL-Injection?

SQL-Injection einfach erklärt

Fast jede Webanwendung speichert ihre Daten in einer Datenbank: Kundenkonten, Bestellungen, Preise. Um Daten abzurufen, schickt die Anwendung Anfragen in der Datenbanksprache SQL (Structured Query Language), etwa: „Zeige alle Bestellungen von Kunde 4711.“

Stellen Sie sich einen gewissenhaften, aber naiven Archivar vor. Er bekommt Zettel mit dem Text „Bitte die Akte heraussuchen von: _“. In der Lücke steht normalerweise ein Name. Schreibt jemand stattdessen „Müller – und außerdem alle anderen Akten“ hinein, erledigt der Archivar beides.

Er unterscheidet nicht zwischen dem Namen, den er suchen soll, und einer zusätzlichen Anweisung. Genau das passiert bei einer SQL-Injection: Die Anwendung baut Eingaben ungeprüft in ihre Datenbankabfrage ein. Die Datenbank hält die eingeschleusten Zeichen dann für einen Teil des Befehls.

So funktioniert eine SQL-Injection

Ein vereinfachtes Beispiel zeigt das Prinzip:

1. Die Anwendung baut eine Abfrage: Eine Login-Seite setzt den eingegebenen Benutzernamen direkt in einen SQL-Befehl ein, etwa SELECT * FROM benutzer WHERE name = 'EINGABE'.
2. Der Angreifer manipuliert die Eingabe: Statt eines Namens gibt er z. B. ' OR '1'='1 ein. Das Hochkomma beendet den Text vorzeitig, der Rest wird Teil des Befehls.
3. Die Bedingung ist immer erfüllt: Die Abfrage lautet nun sinngemäß: „Gib alle Benutzer zurück, deren Name leer ist – oder bei denen 1 gleich 1 ist.“ Weil 1 immer gleich 1 ist, liefert die Datenbank sämtliche Einträge.
4. Die Folgen: Je nach Anwendung kann der Angreifer so Anmeldungen umgehen, ganze Tabellen auslesen sowie Daten ändern oder löschen.

Angreifbar sind nicht nur sichtbare Formularfelder, sondern auch URL-Parameter, Cookies und API-Anfragen. Nicht immer zeigt die Anwendung das Ergebnis direkt an. Bei einer sogenannten blinden SQL-Injection (Blind SQL Injection) erschließen Angreifer die Daten Schritt für Schritt aus indirekten Hinweisen, etwa aus der Antwortzeit des Servers.

Im schlimmsten Fall lassen sich über die Datenbank sogar Befehle auf dem Server ausführen. Dann wird aus der SQL-Injection eine Remote Code Execution.

Ein Beispiel aus der Praxis

Ein Fachhändler für Werkzeuge betreibt einen eigenen Webshop. Bei einem Penetrationstest fällt die Suchfunktion auf: Ein einzelnes Hochkomma im Suchbegriff löst eine Fehlermeldung der Datenbank aus. Weitere Tests zeigen, dass sich über das Suchfeld die gesamte Kundentabelle abfragen ließe – mit Namen, Adressen und den gespeicherten Passwort-Hashes. Hashes sind Passwörter in unumkehrbar umgerechneter Form. Schwache Passwörter lassen sich daraus aber oft durch massenhaftes Ausprobieren ermitteln.

Die Prüfer melden den Befund sofort an die vereinbarte Ansprechperson. Die Entwickler stellen die Suche auf parametrisierte Abfragen um, die Anwendung erhält ein Datenbankkonto mit minimalen Rechten, und Fehlermeldungen zeigen keine technischen Details mehr. Ein Retest bestätigt, dass die Lücke geschlossen ist.

Warum ist das für Unternehmen wichtig?

SQL-Injection ist seit vielen Jahren bekannt – und trotzdem kein Problem der Vergangenheit. Injection-Schwachstellen gehören seit Langem zu den OWASP Top 10, der bekanntesten Übersicht der kritischsten Risiken für Webanwendungen. Automatisierte Werkzeuge suchen im Internet gezielt nach solchen Lücken.

Die Folgen können erheblich sein. Gelangen personenbezogene Daten in fremde Hände, müssen Unternehmen die Datenschutzverletzung nach Art. 33 DSGVO in der Regel unverzüglich und möglichst binnen 72 Stunden der zuständigen Aufsichtsbehörde melden. Hinzu kommen Vertrauensverlust bei Kunden und der Aufwand für die Aufarbeitung.

So schützen Sie sich

• Parametrisierte Abfragen: Prepared Statements trennen Befehl und Daten sauber. Eingaben werden dann immer nur als Daten behandelt – die wirksamste Gegenmaßnahme.
• Frameworks richtig nutzen: Moderne Frameworks, also fertige Programmierbaukästen, schützen meist automatisch. Vorsicht bei selbst zusammengesetzten Abfragen, die diesen Schutz umgehen.
• Eingaben prüfen: Erlauben Sie nur, was erwartet wird – etwa ausschließlich Ziffern in einem Feld für die Kundennummer.
• Minimale Rechte: Das Datenbankkonto der Anwendung darf nur, was es wirklich braucht.
• Neutrale Fehlermeldungen: Nutzende sehen eine allgemeine Meldung, technische Details landen im Protokoll.
• Zusätzliche Schutzschicht: Eine Web Application Firewall kann Angriffe abfangen, ersetzt aber keinen sicheren Code.
• Regelmäßig prüfen: Automatische Prüfungen des Quellcodes (SAST) oder der laufenden Anwendung (DAST) und manuelle Penetrationstests decken Lücken auf, bevor Angreifer sie finden.

Wie Rootsektor unterstützt

Im Penetrationstest für Webanwendungen prüfen wir Ihre Anwendungen und Webshops manuell auf Injection-Lücken und weitere Schwachstellen – orientiert am OWASP Testing Guide. Schnittstellen testen wir im API-Penetrationstest. Kritische Schwachstellen melden wir schon während des Tests sofort – telefonisch oder per E-Mail an die vereinbarte Ansprechperson. Der Retest der behobenen Schwachstellen ist kostenlos.