SQL Injection erklart: Wie Angreifer Daten von Unternehmenswebsites stehlen

Was SQL Injection wirklich ist

SQL Injection ist die alteste und immer noch eine der gefahrlichsten Schwachstellen von Webanwendungen. Sie existiert seit den spaten 1990er Jahren, und trotz Jahrzehnten des Bewusstseins taucht sie mit alarmierender Regelmassigkeit in Produktionswebsites auf. OWASP-Daten aus der Analyse tausender Anwendungen fanden Injection-Schwachstellen in 94% der getesteten Apps. Diese Zahl sollte jeden Unternehmer beunruhigen.

Das Konzept ist einfach: Wenn eine Website Benutzereingaben (ein Login-Formular, ein Suchfeld, einen URL-Parameter) nimmt und direkt in eine Datenbankabfrage einfugt, ohne sie korrekt zu bereinigen, kann ein Angreifer seine eigenen SQL-Befehle einschleusen. Statt eines Benutzernamens gibt er ein Fragment von Datenbankcode ein. Der Server fuhrt diesen Code aus, als ware er eine legitime Abfrage, und der Angreifer erhalt Zugang zu Daten, die er nie sehen sollte.

Wenn Ihre Unternehmenswebsite Kundendaten, Bestellungen, E-Mail-Adressen oder andere Informationen in einer Datenbank speichert, ist SQL Injection eine Bedrohung, die Sie verstehen mussen. Nicht auf theoretischer Ebene, sondern in praktischen Begriffen: Wie macht ein Angreifer das konkret, und wie stoppen Sie ihn?

Wie eine normale Datenbankabfrage funktioniert

Bevor wir uns den Angriff ansehen, verstehen wir, was passiert, wenn alles korrekt funktioniert. Stellen Sie sich ein Login-Formular auf Ihrer Website vor. Ein Benutzer gibt seinen Benutzernamen und sein Passwort ein und klickt auf "Anmelden." Im Hintergrund erstellt Ihre Website eine Datenbankabfrage, die etwa so aussieht:

SELECT * FROM users WHERE username = 'marco' AND password = 'meinpasswort123'

Die Datenbank empfangt diese Abfrage, sucht nach einer Zeile, in der der Benutzername "marco" ist und das Passwort ubereinstimmt, und gibt das Ergebnis zuruck. Einfach und logisch.

Das Problem beginnt, wenn die Anwendung diese Abfrage durch Verkettung von Zeichenketten konstruiert und die Benutzereingabe direkt in die SQL-Anweisung einfugt:

query = "SELECT * FROM users WHERE username = '" + benutzerEingabe + "' AND password = '" + passwortEingabe + "'"

Diese Variable benutzerEingabe enthalt alles, was der Benutzer eingegeben hat. Bei einem normalen Benutzernamen funktioniert alles. Aber was passiert, wenn er etwas anderes eingibt?

Klassische SQL Injection: Der Grundangriff

Statt eines Benutzernamens tippt ein Angreifer dies in das Benutzernamensfeld:

' OR '1'='1' --

Die Anwendung fugt dies in die Abfrage ein und erzeugt:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = 'beliebig'

Schauen wir uns an, was passiert ist. Das Apostroph nach der leeren Zeichenkette schliesst den Benutzernamen-Wert. Das OR '1'='1' fugt eine Bedingung hinzu, die immer wahr ist. Das -- ist ein SQL-Kommentarzeichen, das der Datenbank sagt, alles Folgende zu ignorieren, einschliesslich der Passwortprufung. Das Ergebnis: Die Datenbank gibt alle Benutzer zuruck, weil '1'='1' immer wahr ist. Der Angreifer ist eingeloggt, normalerweise als erster Benutzer in der Tabelle, der oft der Administrator ist.

Dies ist die einfachste Form der SQL Injection, und sie wurde verwendet, um Unternehmen jeder Grosse zu kompromittieren. Der Heartland-Payment-Systems-Vorfall 2008, bei dem 130 Millionen Kreditkartennummern gestohlen wurden, begann mit einem SQL-Injection-Angriff.

Datenextraktion mit UNION-Angriffen

Die Login-Umgehung ist nur der Anfang. Die gefahrlichere Nutzung von SQL Injection ist die Datenextraktion. Ein Angreifer verwendet den SQL-Operator UNION, um zusatzliche Abfragen an die ursprungliche anzuhangen und Daten aus jeder Tabelle der Datenbank zu ziehen.

Wenn zum Beispiel eine Website eine Produktsuche hat, die die Datenbank so abfragt:

SELECT name, preis FROM produkte WHERE kategorie = 'elektronik'

Kann ein Angreifer die Eingabe andern zu:

elektronik' UNION SELECT username, password FROM users --

Die resultierende Abfrage wird:

SELECT name, preis FROM produkte WHERE kategorie = 'elektronik' UNION SELECT username, password FROM users --'

Jetzt zeigt die Seite, die Produktlisten anzeigen sollte, auch jeden Benutzernamen und jedes Passwort aus der Benutzertabelle an.

Blind SQL Injection: Wenn man die Ausgabe nicht sieht

Nicht alle SQL-Injection-Schwachstellen erzeugen sichtbare Ausgaben. Manchmal zeigt die Anwendung keine Abfrageergebnisse auf der Seite an. In diesen Fallen verwenden Angreifer Blind SQL Injection, die langsamer aber ebenso effektiv ist.

Boolean-basierte Blind SQLi

Der Angreifer sendet Abfragen, die der Datenbank Wahr-oder-Falsch-Fragen stellen. Je nachdem, ob sich die Seite unterschiedlich verhalt (Inhalt oder Fehler anzeigt, ladt oder nicht ladt), leitet der Angreifer jeweils ein Bit Information ab.

Um zum Beispiel das erste Zeichen des Admin-Passworts zu extrahieren:

' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') = 'a' --

Wenn die Seite normal ladt, ist das erste Zeichen 'a'. Wenn sie einen Fehler oder anderes Verhalten zeigt, versucht der Angreifer 'b', dann 'c', und so weiter. Zeichen fur Zeichen rekonstruiert er das gesamte Passwort. Automatisierte Tools wie sqlmap schaffen dies in wenigen Minuten.

Zeitbasierte Blind SQLi

Wenn sich nicht einmal das Seitenverhalten andert, nutzen Angreifer Timing. Sie injizieren Abfragen, die die Datenbank fur eine bestimmte Dauer pausieren lassen, wenn eine Bedingung wahr ist:

' AND IF((SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a', SLEEP(5), 0) --

Wenn die Seite 5 Sekunden zum Antworten braucht, ist das erste Zeichen 'a'. Wenn sie sofort antwortet, nicht. Diese Technik ist langsamer, funktioniert aber gegen Anwendungen, die identische Antworten zeigen, unabhangig vom Abfrageergebnis.

SQL Injection zweiter Ordnung (Second-Order)

Dies ist die Variante, die selbst erfahrene Entwickler uberrascht. Bei der SQL Injection zweiter Ordnung wird die bosartige Eingabe wahrend der ersten Interaktion (z.B. bei der Registrierung) sicher in der Datenbank gespeichert. Sie wird beim Speichern korrekt escaped. Aber wenn dieser gespeicherte Wert spater abgerufen und in einer anderen Abfrage ohne erneute Bereinigung verwendet wird, wird die Injection ausgefuhrt.

Beispiel: Ein Benutzer registriert sich mit dem Benutzernamen admin'--. Die Registrierungsabfrage verwendet Prepared Statements, der Wert wird sicher gespeichert. Spater hat die Anwendung eine Passwort-Andernfunktion, die eine Abfrage so konstruiert:

UPDATE users SET password = 'neuespasswort' WHERE username = '" + gespeicherterBenutzername + "'

Wenn der gespeicherte Benutzername admin'-- in diese Abfrage eingefugt wird, entsteht:

UPDATE users SET password = 'neuespasswort' WHERE username = 'admin'--'

Der Angreifer hat gerade das Admin-Passwort geandert. Die Eingabe hat die anfangliche Validierung perfekt bestanden, aber die zweite Verwendung dieser Daten hat die Schwachstelle erzeugt.

Was Angreifer nach dem Eindringen tun

Die Ziele der Angreifer zu verstehen hilft zu begreifen, warum SQL Injection so ernst genommen wird:

• Datenexfiltration: Kundennamen, E-Mail-Adressen, Telefonnummern, Kaufhistorie, Zahlungsdaten. Dies ist das Hauptziel der meisten Angreifer.
• Authentifizierungsumgehung: Sich als Administrator anmelden, um die volle Kontrolle uber die Anwendung zu erlangen.
• Datenmanipulation: Preise andern, Bestellungen manipulieren, bosartige Inhalte in Seiten einfugen.
• Rechteeskalation: Den Datenbankzugang nutzen, um Server-Konfigurationsdateien zu lesen oder Betriebssystembefehle auszufuhren.
• Denial of Service: Tabellen loschen, Datensatze vernichten oder ressourcenintensive Abfragen ausfuhren.

Fur ein Schweizer KMU umfassen die Folgen nicht nur den direkten Schaden, sondern auch Verstesse gegen das Bundesgesetz uber den Datenschutz (nDSG), wenn Kundendaten durch eine vermeidbare Schwachstelle offengelegt werden. Wir haben die vollen Kosten einer Datenpanne in unserem Artikel uber die Kosten einer gehackten Website fur KMU behandelt.

Warum SQL Injection immer noch so verbreitet ist

Man konnte sich fragen, wie eine in den 1990er Jahren entdeckte Schwachstelle immer noch die Mehrheit der Webanwendungen betrifft. Mehrere Faktoren tragen dazu bei:

• Legacy-Code: Websites, die vor Jahren mit veralteten Entwicklungspraktiken erstellt wurden, laufen noch in Produktion.
• Unerfahrene Entwickler: Nicht jeder Entwickler hat eine Sicherheitsausbildung. Viele lernen zuerst Features zu bauen und denken erst spater an Sicherheit.
• Dynamischer Abfrageaufbau: Manche Anwendungen erfordern komplexe Abfragen, die ihre Struktur je nach Benutzereingaben andern. Entwickler greifen manchmal auf Zeichenkettenverkettung zuruck.
• Falsche Sicherheit durch ORMs: ORM-Frameworks generieren SQL automatisch, aber Entwickler konnen dennoch Roh-Abfragen schreiben, wenn das ORM nicht unterstutzt, was sie brauchen.
• Keine Code-Reviews oder Tests: Viele KMU-Websites werden von einem einzelnen Entwickler ohne Code-Review oder Sicherheitstests erstellt.

Reale Datenpannen durch SQL Injection

Dies sind keine theoretischen Szenarien. SQL Injection stand hinter einigen der grossten Datenpannen der Geschichte:

Vorfall	Jahr	Auswirkung
Heartland Payment Systems	2008	130 Millionen Kreditkartennummern gestohlen
Sony Pictures	2011	77 Millionen PlayStation-Network-Konten kompromittiert
Yahoo	2012	450.000 Zugangsdaten uber SQL Injection bei Yahoo Voices geleakt
TalkTalk	2015	157.000 Kundendatensatze gestohlen, 400.000 GBP Bussgeld
Equifax	2017	147 Millionen Datensatze offengelegt

Und das sind die Vorfalle, die Schlagzeilen machen. Tausende kleinere Unternehmen werden jedes Jahr durch SQL Injection kompromittiert, ohne offentliche Bekanntmachung. Ein kleines Unternehmen in Lugano oder im Tessin mit einem verwundbaren Kontaktformular oder Produktkatalog ist genauso exponiert wie ein Grossunternehmen, oft sogar mehr, weil das Sicherheitsmonitoring fehlt, um den Angriff uberhaupt zu erkennen.

Pravention: Prepared Statements (parametrisierte Abfragen)

Die effektivste Verteidigung gegen SQL Injection sind Prepared Statements, auch parametrisierte Abfragen genannt. Statt einen SQL-String durch Einfugen von Benutzereingaben zusammenzubauen, definieren Sie die Abfragestruktur mit Platzhaltern und ubergeben die Benutzereingabe separat:

Verwundbar (Zeichenkettenverkettung):

query = "SELECT * FROM users WHERE username = '" + benutzerEingabe + "'"

Sicher (Prepared Statement):

query = "SELECT * FROM users WHERE username = ?" mit Parameter [benutzerEingabe]

Mit einem Prepared Statement weiss die Datenbank, dass der Platzhalter ein Datenwert ist, kein Teil der SQL-Struktur. Selbst wenn der Benutzer ' OR '1'='1' -- eingibt, behandelt die Datenbank die gesamte Zeichenkette als einen literalen Benutzernamen-Wert. Die Injection schlagt vollstandig fehl.

Jede moderne Programmiersprache und jeder Datenbanktreiber unterstutzt Prepared Statements. Es gibt keine Entschuldigung, sie nicht zu verwenden. Wenn Ihr Webentwickler oder Ihre Agentur Abfragen mit Zeichenkettenverkettung erstellt, ist das ein ernstes Warnsignal bezuglich ihrer Sicherheitspraktiken.

Pravention: Eingabevalidierung

Prepared Statements sind die primare Verteidigung, aber Eingabevalidierung fugt eine zweite Schicht hinzu. Das Prinzip ist einfach: Definieren Sie, wie gultige Eingaben aussehen, und weisen Sie alles andere zuruck.

• Whitelist statt Blacklist: Versuchen Sie nicht, gefahrliche Zeichen herauszufiltern. Definieren Sie stattdessen, was erlaubt ist.
• Typprufung: Wenn ein URL-Parameter eine Ganzzahl sein soll (wie eine Produkt-ID), konvertieren Sie ihn in eine Ganzzahl, bevor Sie ihn verwenden.
• Langenbegrenzungen: SQL-Injection-Payloads neigen dazu, langer als legitime Eingaben zu sein.
• Ausgabekodierung: Selbst wenn die Injection auf SQL-Ebene fehlschlagt, verhindert Ausgabekodierung, dass gespeicherter bosartiger Inhalt als Code im Browser ausgefuhrt wird (dies uberschneidet sich mit der XSS-Pravention, die wir in unserem Artikel XSS erklart behandeln).

Pravention: Web Application Firewall (WAF)

Eine WAF sitzt zwischen Benutzern und Ihrer Webanwendung und inspiziert jede Anfrage auf Muster, die nach Angriffen aussehen. Moderne WAFs konnen SQL-Injection-Versuche in Echtzeit erkennen und blockieren.

Eine WAF ist eine wertvolle Verteidigungsschicht, aber kein Ersatz fur sicheren Code. WAFs konnen umgangen werden. Denken Sie an eine WAF als Sicherheitsnetz, nicht als Ersatz fur korrektes Bauen.

• Cloud-basierte WAFs: Cloudflare, Sucuri, AWS WAF. Am einfachsten zu implementieren.
• WAFs auf Serverebene: ModSecurity mit OWASP Core Rule Set.
• WAFs auf Anwendungsebene: Bibliotheken und Middleware, die Anfragen im Anwendungscode inspizieren.

Pravention: Datenbankzugriff mit minimalen Rechten

Selbst bei erfolgreicher SQL-Injection konnen Sie den Schaden begrenzen, indem Sie einschranken, was der Datenbankbenutzer tun kann:

• Wenn die Anwendung nur Daten aus einer Tabelle liest, sollte der Datenbankbenutzer keine Schreibrechte auf dieser Tabelle haben.
• Der Datenbankbenutzer der Anwendung sollte nie DROP TABLE oder DROP DATABASE Berechtigungen haben.
• Administrative Datenbankoperationen sollten ein separates, privilegierteres Konto verwenden.
• Erwagen Sie verschiedene Datenbankbenutzer fur verschiedene Teile der Anwendung.

Was tun, wenn Sie vermuten, dass Ihre Website verwundbar ist

1. Keine Panik, aber schnell handeln. SQL Injection ist ernst aber behebbar.
2. Fragen Sie Ihren Entwickler oder Ihre Agentur direkt: "Verwenden wir Prepared Statements fur alle Datenbankabfragen?"
3. Fuhren Sie einen automatisierten Scan durch. OWASP ZAP ist kostenlos und kann die haufigsten SQL-Injection-Muster identifizieren.
4. Setzen Sie sofort eine WAF ein. Cloudflares kostenloser Plan beinhaltet grundlegenden WAF-Schutz.
5. Prufen Sie Ihre Logs. Suchen Sie nach Anfragen mit SQL-Schlusselwortern wie UNION, SELECT, DROP.
6. Priorisieren Sie die Behebung. Warten Sie nicht auf den nachsten Entwicklungszyklus. SQL Injection ist eine Sofort-Beheben-Schwachstelle.

Fur einen breiteren Blick auf Schwachstellen von Webanwendungen lesen Sie unsere Aufschlusselung der OWASP Top 10. Und wenn Sie eine professionelle Bewertung Ihrer Website wunschen, kontaktieren Sie unser Team in Lugano.

Das Wesentliche fur Unternehmer

SQL Injection ist weder exotisch noch anspruchsvoll. Es ist eine gut verstandene Schwachstelle mit gut verstandenen Abwehrmassnahmen. Die Tatsache, dass sie immer noch in der Mehrheit der Webanwendungen auftaucht, ist ein Versagen der Entwicklungspraktiken, nicht ein Mangel an verfugbaren Losungen.

Wenn Ihre Website eine Datenbank hat (und wenn sie ein Login-Formular, eine Suchfunktion, einen Produktkatalog oder ein Kontaktformular hat, das Einsendungen speichert, hat sie fast sicher eine), stellen Sie die Frage: Wie werden unsere Datenbankabfragen konstruiert? Die Antwort sollte immer "mit Prepared Statements" lauten. Alles andere ist ein Risiko, das Ihr Unternehmen nicht tragen sollte.