Erfahren Sie, was SQLi-Angriffe sind, auf wen sie abzielen und wie sie sich von anderen Angriffen unterscheiden.
2023 Mid-Year Threat ReportDie Structured Query Language (SQL) ist eine Sprache, mit der Daten in einer Datenbank manipuliert und verwaltet werden können. Seit ihrer Entwicklung wurde SQL fortwährend in viele kommerzielle und Open-Source-Datenbanken eingeführt. SQL-Injektion (SQLi) ist eine Art Cyberangriff, der sich mit speziell entworfenen SQL-Anweisungen an Datenbanken richtet, um die Systeme zu veranlassen, unerwartete, unerwünschte Handlungen auszuführen.
In diesem Video erfahren Sie mehr über SQL-Injektionsangriffe (in unter fünf Minuten):
Zu den Handlungen eines erfolgreichen Angriffs auf ein kompromittiertes Ziel zählen:
Erfolgreiche SQL-Injektionen können für jedes Unternehmen und jede Einzelperson katastrophale Folgen haben. Sobald sensible Daten in einem Angriff kompromittiert wurden, kann eine vollständige Wiederherstellung schwer oder gar unmöglich sein.
Datenbanken sind häufig Ziel einer Injektion über eine Anwendung (z. B. eine Website, die Benutzereingaben anfordert und nach dieser Eingabe eine Datenbank durchsucht), aber sie können auch direkt erfolgen. SQL-Injektionsangriffe sind in der OWASP Top-10-Liste der Sicherheitsrisiken aus Anwendungen für Unternehmen aufgeführt.
SQL-Injektionsangriffe können auf verschiedene Weise durchgeführt werden. Angreifer können das Systemverhalten beobachten, bevor sie einen bestimmten Angriffsvektor oder eine Methode wählen.
Eine unbereinigte Eingabe ist eine häufig auftretende Art eines SQLi-Angriffs, mit dem der Angreifer Benutzereingaben überträgt, die nicht auf Zeichen bereinigt wurden, die maskiert werden müssten, und/oder die Eingabe konnte nicht als korrekte/erwartete Eingabe validiert werden.
So kann eine Website zur Rechnungsbegleichung die Kontonummer des Benutzers in einem Webformular anfordern und diese dann an die Datenbank übertragen, um die zugehörigen Kontoinformationen abzufragen. Wenn die Webanwendung aus der eingegebenen Benutzerkontonummer dynamisch eine SQL-Abfragezeichenfolge aufbaut, könnte diese so aussehen:
“SELECT * FROM Kunden WHERE Konto = ‘“ + userProvidedAccountNumber +”’;”
Dies stellt für Benutzer, die ihre Kontonummer richtig eingeben, kein Problem dar, bietet jedoch eine Angriffsfläche. Sollte jemand beispielweise die Kontonummer als “‘ or ‘1’ = ‘1” eingeben, ergäbe sich diese Abfragezeichenfolge:
“SELECT * FROM Kunden WHERE Konto = ‘’ or ‘1’ = ‘1’;”
Da ‘1’ = ‘1’ immer als TRUE ausgewertet wird, führt der Versand dieser Anweisung an die Datenbank dazu, dass statt der Daten eines einzelnen Kunden die Daten aller Kunden zurückgegeben werden.
Ein blinder SQL-Injektionsangriff, der auch als „Inferential SQL Injection“ bezeichnet wird, zeigt die Daten aus der angegriffenen Datenbank nicht direkt an. Stattdessen untersucht der Angreifer die Verhaltensweise genau auf indirekte Anzeichen. Zu den Dingen, die je nach den Absichten des Angreifers Anzeichen sein können, zählen Details aus der HTTP-Antwort, leere Webseiten bei bestimmten Benutzereingaben und die Dauer, bis die Datenbank auf bestimmte Benutzereingaben reagiert. Sie könnten auch auf einen weiteren SQLi-Angriffspfad hinweisen, den der Angreifer ausprobieren könnte.
Dieser Angriff ist etwas komplexer und kann von Angreifern eingesetzt werden, wenn sie ihr Ziel nicht über einen einzigen direkten Abfrage-Antwort-Angriff erreichen. In der Regel stellt ein Angreifer SQL-Anweisungen aus, die bei Eintreffen in der Datenbank dazu führen, dass das Datenbanksystem eine Verbindung zu einem externen Server herstellt, den der Angreifer kontrolliert. Auf diese Weise kann der Angreifer Daten abrufen oder das Verhalten der Datenbank möglicherweise steuern.
Eine „Second Order Injection“ ist eine Art eines Out-of-Band-Injektionsangriffs. In dem Fall stellt der Angreifer eine SQL-Injektion zur Verfügung, die durch ein separates Verhalten des Datenbanksystems gespeichert und ausgeführt wird. Wenn das sekundäre Systemverhalten auftritt (dabei kann es sich um einen befristeten Auftrag oder eine von typischem Administrator- oder Benutzergebrauch der Datenbank ausgelöste Aktion handeln) und die SQL-Injektion des Angreifers ausgeführt wird, geschieht die „Kontaktaufnahme“ mit einem System, das der Angreifer kontrolliert.
In diesem Beispiel einer SQL-Injektion verwenden wir zwei Datenbanktabellen: Benutzer und Kontakte. Die Benutzertabelle hat möglicherweise nur drei Felder: ID, Benutzername und Passwort. Die Kontakttabelle enthält mehr Informationen über die Benutzer, wie z. B. UserID, Vorname, Nachname, Addresse1, E-Mail, Kreditkartennummer und Prüfzahl.
Die Benutzertabelle enthält Informationen aus den Anmeldungen wie:
Hinweis: Passwörter sollten zur Speicherung in der Datenbank immer verschleiert (###*#**) und nie als Klartext angezeigt werden.
Zur Anmeldung geht der Benutzer auf die Login-Seite und gibt seinen Benutzernamen und ein Passwort ein. Diese Informationen werden dann an den Webserver geschickt, der eine SQL-Abfrage erstellt und diese Abfrage an den Datenbankserver sendet. Ein Beispiel, wie diese Abfrage aussehen könnte:
Select ID from Users where username=’jschmitt’ and password=’P@$$w0rt’
SQL führt dann sachgemäß einen True- und False-Vergleich in allen von der Abfrage aufgerufenen Zeilen durch. In unserem Beispiel sieht die Abfrage vor, dass die Benutzertabelle abgefragt wird und den ID-Wert aus jeder Zeile zurückgibt, in der der Benutzername jschmitt und das Passwort P@$$w0rt lauten. Häufig erkennt der Webserver dann, was der Datenbankserver zurückgegeben hat und ob es sich dabei um eine Zahl handelt. In unserem Fall würde der Webserver eine 1 zurückerhalten und dem Benutzer nach der Anmeldeseite Zugang gewähren.
Aber was wäre, wenn dies unter vorgetäuschten Gründen erfolgen würde? Da der Datenbankserver diese True- oder False-Prüfung vornimmt, können wir ihn täuschen, dass wir uns erfolgreich authentifiziert haben. Dies erfolgt durch den Zusatz von OR zum Passwort. Wenn wir uns mit x’ or 1=1 als Passwort anmelden, entsteht eine neue SQL-Abfrage, die so aussieht:
Select ID from Users where username=’jschmitt’ and password=’x’ or 1=1
Das funktioniert, obwohl x nicht das Passwort von jschmitt ist, denn der Datenbankserver überprüft dann die zweite Bedingung. Wenn x nicht das Passwort von jschmitt ist, stimmt es, dass 1 gleich 1 ist? Ja, das stimmt! Die ID wird an die Anwendung zurückgesendet und der Benutzer erfolgreich authentifiziert.
Es muss sich nicht um eine 1=1 Bedingung handeln. Jegliche zwei identischen Werte funktionieren genauso: 2=2, 4726=4726 oder sogar a=a.
Wenn eine Webseite Daten anzeigen kann, kann sie auch zusätzliche Daten auf dem Bildschirm anzeigen. Um auf die Daten zuzugreifen, können wir versuchen, zwei SQL-Abfragen zu verknüpfen. Neben unserem ‘ or 1=1 können wir diesen eine zweite Anweisung wie UNION SELECT LastName, Kreditkartennummer, Prüfzahl aus den Kontakten hinzufügen. Zusätzliche Klauseln wie diese erfordern etwas mehr Aufwand, aber Datenzugriff ist das letztendliche Ziel eines SQL-Injektionsangriffs.
Eine weitere Methode, die sich für die blinde SQL-Injektion eignet, mit der keine Daten an den Bildschirm zurückgesandt werden, wäre die Injektion anderer Hinweise. Ähnlich wie bei der ‘ or 1=1 Bedingung können wir den Server anweisen, in den Schlafzustand zu wechseln. Wir könnten hinzufügen: “ ‘ or sleep(10) ” und das bewirkt genau, was es besagt. Es teilt dem Datenbankserver mit, für zehn Sekunden in den Ruhezustand zu gehen, in dem alle Antworten verzögert werden.
Die folgenden Vorschläge können dazu beitragen, einen erfolgreichen SQL-Injektionsangriff zu verhindern:
Verwenden Sie kein dynamisches SQL
Bereinigen Sie die Benutzereingaben
Lassen Sie keine vertraulichen Daten als Klartext stehen
Schränken Sie den Zugriff auf die Datenbank und die Berechtigungen weiter ein
Vermeiden Sie es, Benutzern Datenbankfehler direkt anzuzeigen
Verwenden Sie eine Web Application Firewall (WAF) für Webanwendungen mit Zugriff auf Datenbanken.
Verwenden Sie eine Webanwendung-Sicherheitstestlösung, um Web-Apps, die mit Datenbanken interagieren, routinemäßig zu testen.
Aktualisieren Sie Ihre Datenbanken auf den neuesten verfügbaren Patch.
SQL-Injektion ist für Widersacher eine beliebte Angriffsmethode, aber wenn Sie die richtigen Vorsichtsmaßnahmen ergreifen, wie z. B. die Datenverschlüsselung, den Schutz und die Tests Ihrer Webanwendungen und die Aktualisierung auf die neuesten Patches, sind Sie auf dem richtigen Weg, um Ihre Daten zu schützen.