SQL-Injection SQLi

Was SQL-Injection ist

Sie betreiben einen Onlineshop. Ein Besucher tippt etwas Seltsames in das Suchfeld, drückt Enter, und die Seite zeigt ihm Namen, Telefonnummern und Bestellungen aller Ihrer Kunden. Niemand hat ein Passwort gestohlen. Er hat die richtigen Worte an der falschen Stelle eingegeben, und Ihre Website hat den Rest erledigt. Genau das ist SQL-Injection.

Die meisten Websites speichern ihre Informationen in einer Datenbank: einem geordneten Speicher aus Tabellen, ähnlich wie eine Sammlung von Tabellenblättern. Um diese Informationen zu lesen oder zu ändern, spricht die Website eine Sprache namens SQL (Structured Query Language). Jede Anfrage, die sie schickt, ist eine Abfrage, zum Beispiel „finde den Kunden mit dieser E-Mail-Adresse“.

SQL-Injection passiert, wenn eine Website das, was ein Besucher eingibt, direkt in eine dieser Abfragen einfügt. Tippt der Besucher SQL statt normalem Text, merkt die Datenbank keinen Unterschied und folgt dem Befehl des Angreifers, als hätte die Website ihn selbst geschrieben. Oft wird der Name zu SQLi abgekürzt.

Wie ein SQL-Injection-Angriff abläuft

Stellen Sie sich einen Bankangestellten vor, der jeden Zettel eines Kunden Wort für Wort an die Leute im Tresorraum weitergibt. Ein normaler Zettel sagt „Zeigen Sie mir meinen Kontostand“. Ein listiger Zettel sagt „Zeigen Sie mir meinen Kontostand, und öffnen Sie auch alle Schließfächer“. Liest der Angestellte den Zettel vorher nie, gehorchen die Leute im Tresorraum.

Auf einer Website laufen die Schritte meist so ab:

1. Der Angreifer sucht eine Stelle, die Text an die Datenbank schickt: ein Login-Formular, ein Suchfeld, ein Kontaktformular oder die Webadresse selbst, etwa eine Produktseite, die auf „?id=25“ endet.
2. Er gibt ein kleines Stück SQL statt normalem Text ein. Ein bekanntes Beispiel ist die Eingabe von ' OR '1'='1 in das Passwortfeld eines Login-Formulars.
3. Die Website hängt diesen Text ungeprüft an ihre eigene Abfrage an. Die Abfrage lautet dann ungefähr „lass diese Person rein, wenn das Passwort stimmt oder wenn 1 gleich 1 ist“.
4. Da 1 immer gleich 1 ist, antwortet die Datenbank mit Ja, und der Angreifer ist eingeloggt, ohne ein Passwort zu kennen.

Manche Angriffe laufen leiser ab. Bei einer blinden SQL-Injection zeigt die Seite gar keine Daten an. Der Angreifer stellt der Datenbank deshalb Ja-oder-Nein-Fragen und beobachtet, wie die Seite reagiert oder wie lange sie zum Laden braucht. Von Hand ist das mühsam, darum lassen Angreifer kostenlose automatische Tools diese Arbeit machen.

Was ein Angreifer damit tun kann

Sobald die Datenbank seinen Befehlen folgt, hängt der Schaden davon ab, was das Datenbankkonto der Website darf. Oft ist das viel mehr, als die Website braucht. Ein Angreifer kann dann unter Umständen:

• private Daten lesen, etwa Namen, Adressen, E-Mails und Bestellungen von Kunden, Patientenakten oder gespeicherte Passwörter
• sich als anderer Nutzer anmelden, auch als Administrator
• Daten ändern, zum Beispiel Preise, Guthaben oder den Status von Bestellungen
• ganze Tabellen löschen oder die komplette Datenbank
• bei manchen Systemen bis zum Server selbst gelangen und dort schädliche Dateien ablegen

Warum das für Ihr Unternehmen wichtig ist

SQL-Injection gehört zu den ältesten Angriffen im Web, und es gibt sie noch immer. OWASP, eine offene Gemeinschaft, die die bekannte Liste OWASP Top 10 der Risiken für Webanwendungen veröffentlicht, führt Injection seit Jahren auf dieser Liste. Der Angriff ist leicht auszuprobieren, und viele Websites haben noch irgendein vergessenes Formular, das ihn durchlässt.

Für Unternehmer ist der eigentliche Schaden selten technisch. Es ist eine geleakte Kundenliste, ein Shop, der zum falschen Preis verkauft, ein Buchungssystem, das eine Woche Termine verliert, oder eine Nachricht, mit der Sie Ihren Kunden sagen müssen, dass ihre Daten offengelegt wurden. In vielen Ländern verlangen Datenschutzgesetze wie die DSGVO (GDPR) außerdem, dass Sie personenbezogene Daten schützen und Datenpannen melden.

Wurde jedes Formular auf Ihrer Website mit diesem Risiko im Blick gebaut? Websites, die schnell aus alten Plugins zusammengesetzt oder über die Jahre von vielen Händen geändert wurden, verstecken eher eine Schwachstelle.

Wie Sie eine Website vor SQL-Injection schützen

Die wichtigste Lösung ist gut bekannt, und sie wirkt. Der größte Teil des Schutzes steckt in der Art, wie die Website gebaut ist. Das sind also gute Fragen an Ihre Entwickler oder Ihren Anbieter.

• Prepared Statements. Man nennt sie auch parametrisierte Abfragen. Die Website schickt die Abfrage und den Text des Besuchers getrennt, sodass die Datenbank den Text immer als reine Daten behandelt und nie als Befehl. Das ist der wichtigste Schutz. Moderne Frameworks wie Laravel machen das standardmäßig, wenn Entwickler ihre eingebauten Datenbankwerkzeuge nutzen.
• Eingabeprüfung. Ein Feld für die Telefonnummer sollte nur Ziffern annehmen, ein Datumsfeld nur Daten. Wer seltsame Eingaben früh abweist, schließt viele Türen.
• Minimale Rechte. Das Konto, mit dem die Website auf die Datenbank zugreift, sollte nur die Rechte haben, die es braucht. Eine öffentliche Suchseite hat keinen Grund, Tabellen zu löschen.
• Zurückhaltende Fehlermeldungen. Ein ausführlicher Datenbankfehler auf dem Bildschirm ist für Angreifer wie eine Landkarte. Zeigen Sie Besuchern eine kurze, einfache Meldung und speichern Sie die Details in privaten Logs.
• Updates. Halten Sie Plattform, Plugins und Bibliotheken aktuell, denn alte Versionen haben oft bekannte Lücken.
• Eine Web Application Firewall. Das ist ein Filter vor der Website, der viele bekannte Angriffsmuster blockiert, bevor sie Ihren Code erreichen. Sie hilft, repariert aber keinen unsicheren Code.
• Regelmäßige Tests. Penetrationstests (ein sicherer, geplanter Angriff durch Fachleute) und Schwachstellen-Scans finden die schwachen Stellen, bevor ein Angreifer es tut.

So schneiden typische Gewohnheiten im Vergleich ab:

Typische Fehler

• Auf Prüfungen im Browser vertrauen. Prüfungen, die auf dem Gerät des Besuchers laufen, lassen sich leicht umgehen. Der Server muss deshalb alles noch einmal prüfen.
• Glauben, eine kleine Website sei sicher. Automatische Tools durchsuchen riesige Mengen an Websites, ganz gleich, wie groß sie sind.
• Ein Formular reparieren und die anderen vergessen. Suchfeld, Filter, Webadresse und die API hinter einer mobilen App brauchen alle dieselbe Sorgfalt.
• Passwörter im Klartext speichern. Kommt es zu einem Datenleck, sind Passwörter mit starkem Hashing (in einen unlesbaren Code umgewandelt, der sich nicht zurückverwandeln lässt) viel schwerer zu missbrauchen.
• Sich allein auf eine Firewall verlassen. Ein Filter verschafft Zeit. Die unsichere Abfrage dahinter muss trotzdem behoben werden.

Wie wir helfen können

Bei Linkysoft gehört die Suche nach SQL-Injection zu unseren Leistungen für Cybersicherheit. Wir führen sichere, simulierte Angriffe auf Ihre Website, Ihre App und Ihre API durch, prüfen den Code und geben Ihnen eine verständliche Liste mit unseren Funden und den passenden Lösungen. Nach den Korrekturen testen wir erneut. Das funktioniert auch bei Websites, die andere Teams gebaut haben, und der kostenlose Sicherheitscheck ist ein einfacher erster Schritt.

Sie planen ein neues System? Unsere Webanwendungen und Verwaltungssysteme sind von Anfang an sicher gebaut, mit Härtung nach den OWASP Top 10 und Penetrationstests vor dem Start.