Der Stand der SQL Injection

SQL-Injection (SQLi) hat eine Geschichte, die älter ist als der Internet Explorer (der laut Gen Z der Beginn der Zivilisation war). Tausende von Sicherheitsverletzungen wurden durch SQL-Injection verursacht, und es gibt unzählige gut dokumentierte Best Practices und Tools, um sie zu verhindern. Sicherlich haben wir aus diesen Vorfällen gelernt, und SQLi ist kein Problem mehr.

Wir haben die Anzahl der in Open-Source- und Closed-Source-Projekten entdeckten SQL-Injections überwacht, um festzustellen, ob sich die Lage verbessert. Angesichts der jüngsten Nachrichten, dass gestohlene Daten aus dem MOVEit SQL-Injection-Angriff an Unternehmen wie Amazon verkauft werden, haben wir beschlossen, Ihnen einen ersten Einblick in unseren kommenden State of Injection Report für 2025 zu geben.

Spoiler: Es stellt sich heraus, dass wir immer noch schlecht darin sind, SQL-Injection zu verhindern.

Was ist SQL-Injection?

SQLi ist eine Schwachstelle, die auftritt, wenn ein Programm nicht vertrauenswürdige Benutzereingaben direkt in einer Abfrage an eine SQL-Datenbank verwendet. Ein bösartiger Benutzer kann dann eigenen Code einfügen und die Abfrage manipulieren, wodurch er auf private Daten zugreifen, die Authentifizierung umgehen oder Daten löschen kann. Das untenstehende Beispiel zeigt, wie eine unsichere SQL-Abfrage für eine Benutzeranmeldeseite anfällig für einen SQLi-Authentifizierungs-Bypass-Angriff ist.

Es gibt viele verschiedene Arten von Injection-Angriffen, wie Code Injection oder Cross-Site-Scripting. Aber SQLi hat insbesondere bei Sicherheitsverletzungen seit sehr langer Zeit eine prominente Rolle gespielt, und es ist für viele schockierend, dass wir dies im Jahr 2024 immer noch diskutieren müssen.

Wie ein SQLi-Angriff abläuft

1. Anfällige Abfrage
Beispiel einer anfälligen Abfrage, bei der Benutzereingaben direkt in der Abfrage verwendet werden

2. SQL-Injection-Angriff
SQL wird in das Benutzereingabefeld einer Authentifizierungsseite injiziert

3. Abfrageausführung mit PayloadDie Payload kommentiert die Passwortprüfung aus, sodass die Abfrage diesen Schritt ignoriert.

SQL-Injection in Zahlen:

• 6,7 % aller in Open-Source-Projekten gefundenen Schwachstellen sind SQLi
• 10 % für Closed-Source-Projekte!
• Es wird ein Anstieg der Gesamtzahl von SQL-Injections in Open-Source-Projekten (CVEs’s, die SQLi betreffen) von 2264 (2023) auf 2400 (2024) erwartet.
• Als Prozentsatz aller Schwachstellen wird SQL Injection weniger populär: ein Rückgang um 14 % bzw. 17 % bei Open-Source- bzw. Closed-Source-Projekten von 2023 bis 2024.
• Über 20 % der gescannten Closed-Source-Projekte sind anfällig für SQL-Injection, wenn sie zum ersten Mal Sicherheitstools einsetzen.
• Für Organisationen, die anfällig für SQL-Injection sind, beträgt die durchschnittliche Anzahl der SQL-Injection-Stellen fast 30 separate Orte im Code

Wir haben untersucht, wie viele SQLi-Schwachstellen in Open-Source-Paketen im Jahr 2023 und bisher im Jahr 2024 entdeckt wurden. Dies haben wir dann mit Closed-Source-Projekten verglichen, die von Aikido Security entdeckt wurden. Es überrascht nicht, dass wir immer noch schockierende Zahlen von SQL-Injection-Schwachstellen sowohl in Closed- als auch in Open-Source-Projekten sehen. 6,7 % aller im Jahr 2024 in Open-Source-Projekten entdeckten Schwachstellen sind SQL-Injection-Schwachstellen, während 10 % der in Closed-Source-Projekten entdeckten Schwachstellen SQL-Injection-Schwachstellen waren. Das mag nicht viel erscheinen, aber es ist ehrlich gesagt schockierend, dass wir im Jahr 2024 immer noch Schwierigkeiten haben, mit einigen der grundlegendsten Schwachstellen umzugehen, die wir kennen.

Die einzige gute Nachricht, die wir haben, ist, dass diese Zahl einen Rückgang von 14 % gegenüber 2023 bei Open-Source-Projekten und eine Reduzierung um 17 % bei Closed-Source-Projekten als Prozentsatz aller gefundenen Schwachstellen darstellt. Es wird jedoch erwartet, dass die Gesamtzahl der gefundenen SQLi in Open-Source-Projekten von 2264 im Jahr 2023 auf über 2400 bis Ende 2024 ansteigen wird.

Verhinderung von SQL-Injection

Anscheinend gibt es im Internet noch nicht genügend Informationen zur Vermeidung von SQL-Injection, daher finden Sie hier eine Übersicht der im Jahr 2025 verfügbaren Optionen:

1. Verwenden Sie Prepared Statements und parametrisierte Abfragen

Im Beispiel zu Beginn dieses Blogbeitrags zeigten wir anfälligen Code, da er nicht vertrauenswürdige Benutzereingaben entgegennimmt und diese direkt in einer Abfrage verwendet. Um dies zu vermeiden, sollten wir Prepared Statements verwenden, was bedeutet, Ihre Abfrage zuerst zu definieren und dann später Benutzereingaben hinzuzufügen. Dies trennt den Befehls- und Datenstrom und behebt das Problem vollständig. Eine großartige Lösung, aber nicht immer möglich oder genutzt!

import sqlite3
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
user_id = 5 # Beispiel für sichere Eingabe
# Sichere Abfrage mit parametrisierter Abfrage

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2. Serverseitige Eingabe-/Schema-Validierung

Eingabevalidierung kann bei der Verhinderung von SQLi wirksam sein. Wenn Ihre API beispielsweise eine E-Mail-Adresse oder eine Kreditkartennummer erwartet, lässt sich die Validierung für diese Fälle einfach hinzufügen.

3. SAST- & DAST-Tools verwenden, um SQLi zu entdecken

Eines der erschreckendsten Elemente von SQLi ist, dass es von Angreifern leicht entdeckt werden kann und oft als „Low-Hanging-Fruit“-Schwachstelle beschrieben wird. Ein Grund dafür ist, dass Tools wie DAST sie automatisch entdecken können. Dies können wir zu unserem Vorteil nutzen und diese Tools in unseren Entwicklungsprozess integrieren, um sie frühzeitig zu erkennen.

Next-Gen SAST-Tools wie Aikido ermöglichen es Ihnen auch, die Probleme direkt innerhalb der Plattform automatisch zu beheben.

4. Eine In-App-Firewall implementieren

Eine In-App-Firewall überwacht den Traffic und die Aktivitäten innerhalb Ihrer Anwendung und kann Angriffe, einschließlich Injection und SQLi, erkennen. Dies ist effektiver als eine herkömmliche WAF, da sie sich innerhalb Ihrer Anwendung befindet und in der Lage ist, erwartete Abfragen zu tokenisieren und Anfragen zu blockieren, die die Befehlsstruktur der Abfrage ändern.

Schamlose Eigenwerbung ;) für Aikidos neue Einführung: Zen, die In-App-Firewall für mehr Sicherheit zur Laufzeit. Holen Sie sich Zen und es blockiert kritische Injection-Angriffe und Zero-Day-Bedrohungen automatisch in Echtzeit, bevor sie Ihre Datenbank erreichen.

5. Dynamisches SQL möglichst vermeiden

Dynamische SQL-Generierung durch String-Verkettung ist hochgradig anfällig für SQL-Injection. Halten Sie sich, wann immer möglich, an statische, vordefinierte Abfragen und gespeicherte Prozeduren, die nicht auf benutzergenerierten Inhalten für die SQL-Struktur basieren.

6. Allowlisting und Escaping

In einigen Fällen lässt sich Dynamic SQL nicht vermeiden, z. B. beim Abfragen dynamischer Tabellen oder wenn Sie nach einer benutzerdefinierten Spalte und Richtung sortieren möchten. In diesen Fällen bleibt Ihnen keine andere Möglichkeit, als sich auf die Zulassungsliste von regulären Ausdrücken oder auf Escaping zu verlassen. Escaping bedeutet, Benutzereingaben, die gefährliche Zeichen wie „>“ enthalten, in eine sichere Form umzuwandeln. Entweder durch Hinzufügen von Backslashes davor oder durch Umwandlung in einen Symbolcode. Beachten Sie, dass dies nicht nur für jeden Datenbanktyp unterschiedlich ist, sondern auch von den Verbindungseinstellungen wie dem Zeichensatz abhängen kann.

Werden wir jemals das Ende von SQLi erleben?

Obwohl es vielversprechend ist, dass wir einen einigermaßen deutlichen Rückgang der gefundenen SQLi-Schwachstellen verzeichnen konnten, ist es dennoch entmutigend zu sehen, dass eine Schwachstelle, die älter ist als das Spiel DOOM, immer noch eine so erhebliche Bedrohung für die IT-Landschaft darstellt. Die Wahrheit ist, ich sehe nicht, dass sich dies wesentlich verbessern wird. Während wir immer mehr Tools einführen, die uns helfen, schneller zu coden, verlieren Entwickelnde den Bezug zu den grundlegenden Codierungsprinzipien, und diese KI-Tools sind notorisch schlecht darin, anfälligen Code mit Injection-Schwachstellen vorzuschlagen.

Es ist jedoch nicht alles düster (Wortspiel beabsichtigt): Wir beobachten erhebliche Verbesserungen bei einer neuen Generation von SAST-Tools, die wesentlich effektiver bei der Erkennung und Behebung dieser Schwachstellen sind und das Potenzial haben, die Bedrohungslandschaft drastisch zu verändern.

Zum Abschluss, vergessen Sie nicht:

SQL-Injection mit Aikido AI SAST Autofix erkennen und automatisch beheben

Nutzen Sie Zen und verhindern Sie Injection-Angriffe, sobald sie auftreten

Bonus: SQL-Historie im Wandel der Zeit

Seit wir über Sicherheit in unseren Anwendungen sprechen, sprechen wir über SQL-Injection. Sie wurde bereits 2003 auf Platz 7 der allerersten OWASP Top 10 Liste aufgeführt, 2010 in die Kategorie „Injection“ aufgenommen und belegte bis 2021 den ersten Platz. Einer der ersten groß angelegten Angriffe, der dokumentiert wurde und SQL-Injection involvierte, war der Angriff auf das Bekleidungsunternehmen Guess, der zum Diebstahl von Kreditkartennummern führte. Seitdem ist SQL-Injection ein regelmäßiger Gast in den Sicherheits-Schlagzeilen.

Bonus Teil 2 – Sehen Sie sich Injection Attacks 101 an, um eine Einführung in SQL-Injections, Code-Injections und XSS zu erhalten.