SQL-Injection (SQLi) hat eine Geschichte, die älter ist als der Internet Explorer (der laut der Generation Z der Beginn der Zivilisation war). Es gab Tausende von Sicherheitslücken, die durch SQL-Injection verursacht wurden, und eine unendliche Menge gut dokumentierter bewährter Verfahren und Tools, die helfen, dies zu verhindern. Sicherlich haben wir unsere Lektion aus diesen Verstößen gelernt und SQLi ist kein Thema mehr.
Wir haben die Anzahl der in Open-Source- und Closed-Source-Projekten entdeckten SQL-Injections überwacht, um zu sehen, ob wir besser werden. Angesichts der jüngsten Nachrichten, dass gestohlene Daten aus der MOVEit-SQL-Injection-Verletzung für Unternehmen wie Amazon verkauft werden, haben wir beschlossen, Ihnen einen kleinen Einblick in unseren kommenden State of Injection-Bericht für 2025 zu geben.
Spoiler: Es hat sich herausgestellt, dass wir immer noch schlecht darin sind, SQL-Injection zu verhindern.
Was ist eine SQL-Injektion?
SQLi ist eine Sicherheitslücke, die auftritt, wenn ein Programm nicht vertrauenswürdige Benutzereingaben direkt in einer Abfrage an eine SQL-Datenbank verwendet. Ein böswilliger Benutzer kann dann seinen eigenen Code einfügen und die Abfrage manipulieren, wodurch der böswillige Benutzer auf private Daten zugreifen, die Authentifizierung umgehen oder Daten löschen kann. Das folgende Beispiel zeigt, wie eine unsichere SQL-Abfrage für eine Benutzeranmeldeseite für einen SQLi-Authentifizierungsumgehungsangriff anfällig ist.
Es gibt viele verschiedene Arten von Injektionsangriffen wie Code-Injection oder Cross-Site-Scripting (XSS). Aber speziell SQLi spielt schon seit langem eine wichtige Rolle bei Sicherheitsverletzungen, und es ist für viele schockierend, dass wir im Jahr 2024 immer noch über dieses Thema sprechen müssen.
Wie ein SQLi-Angriff abläuft
1. Angreifbare Abfrage
Beispiel einer angreifbaren Abfrage, bei der Benutzereingaben direkt in der Abfrage verwendet werden
2. SQL-Injektionsangriff
SQL wird in das Benutzereingabefeld einer Authentifizierungsseiteinjiziert
3. Abfrage mit payloadPayloadkommentiert die Passwortprüfung aus, so dass die Abfrage diesen Schritt ignoriert
SQL-Injection nach Zahlen:
- 6,7 % aller in Open-Source-Projekten gefundenen Sicherheitslücken sind SQLi
- 10 % für Closed-Source-Projekte!
- Es wird ein Anstieg der Gesamtzahl der SQL-Injektionen in Open-Source-Projekten (CVEs, die SQLi betreffen) von 2264 (2023 ) auf 2400 (2024 ) erwartet.
- Der prozentuale Anteil von SQL-Injection an allen Schwachstellen nimmt ab: ein Rückgang von 14 % bei Open-Source- und 17 % bei Closed-Source-Projekten von 2023 bis 2024
- Über 20 % der gescannten Closed-Source-Projekte sind anfällig für SQL-Injektionen, wenn sie zum ersten Mal Sicherheitstools verwenden
- Bei Unternehmen, die für SQL-Injection anfällig sind, liegt die durchschnittliche Anzahl der SQL-Injection-Sites bei fast 30 verschiedenen Stellen im Code
Wir haben überprüft, wie viele SQLi-Schwachstellen in Open-Source-Paketen im Jahr 2023 und bisher im Jahr 2024 entdeckt wurden. Anschließend haben wir dies mit den von Aikido Security entdeckten Closed-Source-Projekten verglichen. Es überrascht nicht, dass wir immer noch eine schockierende Anzahl von SQL-Injektionen sowohl in geschlossenen als auch in Open-Source-Projekten feststellen. 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 sind. Das mag nicht viel erscheinen, aber es ist ehrlich gesagt schockierend, dass wir im Jahr 2024 immer noch mit einigen der grundlegendsten Sicherheitslücken, die wir kennen, zu kämpfen haben.
Die einzige gute Nachricht ist, dass diese Zahl im Verhältnis zu allen gefundenen Schwachstellen im Jahr 2023 bei Open-Source-Projekten um 14 % und bei Closed-Source-Projekten um 17 % gesunken ist. Allerdings wird erwartet, dass die Gesamtzahl der gefundenen SQLi in Open-Source-Projekten von 2264 im Jahr 2023 auf über 2400 bis Ende 2024 ansteigen wird.
Verhindern von SQL-Injektion
Offensichtlich gibt es im Internet noch nicht genügend Informationen darüber, wie man SQL-Injection verhindern kann. Deshalb hier ein Überblick über die im Jahr 2025 verfügbaren Optionen:
1. Vorbereitete Anweisungen und parametrisierte Abfragen verwenden
In dem Beispiel zu Beginn dieses Blogbeitrags haben wir anfälligen Code gezeigt, weil er nicht vertrauenswürdige Benutzereingaben direkt in einer Abfrage verwendet. Um dies zu vermeiden, sollten wir vorbereitete Anweisungen verwenden, d. h. die Abfrage wird zuerst definiert und die Benutzereingaben werden später hinzugefügt. Dadurch werden Befehl und Datenstrom getrennt und das Problem vollständig behoben. Eine großartige Lösung, die aber nicht immer möglich ist oder verwendet wird!
import sqlite3
conn = sqlite3.connect('beispiel.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. Server-seitige Eingabe-/Schema-Validierung
Die Validierung von Eingaben kann SQLi wirksam verhindern. Wenn Ihre API zum Beispiel eine E-Mail-Adresse oder eine Kreditkartennummer erwartet, ist es einfach, eine Validierung für diese Fälle hinzuzufügen.
3. SAST- und DAST-Tools verwenden, um SQLi zu entdecken
Eines der furchterregendsten Elemente von SQLi ist, dass es von Angreifern leicht entdeckt werden kann und oft als eine niedrig hängende Schwachstelle bezeichnet wird. Dies liegt zum Teil daran, dass Tools wie DAST sie automatisch entdecken können. Dies kann zu unserem Vorteil genutzt werden, und wir können diese Tools in unseren Entwicklungsprozess integrieren, um sie frühzeitig zu erkennen.
SAST-Tools der nächsten Generation wie Aikido ermöglichen es Ihnen auch, die Probleme direkt von der Plattform aus zu beheben.
4. Implementierung einer In-App-Firewall
Eine In-App-Firewall überwacht den Datenverkehr und die Aktivitäten innerhalb Ihrer Anwendung und kann Angriffe wie Injection und SQLi erkennen. Sie 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 Werbung ;) für Aikidos Neueinführung : Zendie In-App-Firewall für mehr Sicherheit während der Laufzeit. Holen Sie sich Zen und es blockiert automatisch kritische Injektionsangriffe und Zero-Day-Bedrohungen in Echtzeit, bevor sie überhaupt Ihre Datenbank erreichen.
5. Dynamisches SQL nach Möglichkeit vermeiden
Die dynamische SQL-Generierung durch String-Verkettung ist sehr anfällig für SQL-Injection. Wann immer möglich, sollten Sie statische, vordefinierte Abfragen und gespeicherte Prozeduren verwenden, die sich nicht auf benutzergenerierte Inhalte für die SQL-Struktur stützen.
6. Auflistung und Escaping zulassen
In einigen Fällen lässt sich Dynamic SQL nicht vermeiden, z. B. bei der Abfrage dynamischer Tabellen oder wenn Sie nach einer benutzerdefinierten Spalte und Richtung ordnen möchten. In diesen Fällen bleibt Ihnen nichts anderes übrig, als sich auf die Auflistung regulärer Ausdrücke oder das Escaping zu verlassen. Beim Escaping werden Benutzereingaben, die gefährliche Zeichen wie ">" enthalten, in eine sichere Form umgewandelt. Entweder durch Hinzufügen von Backslashes vor den Zeichen 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?
Es ist zwar vielversprechend, dass die Zahl der gefundenen SQLi-Schwachstellen etwas zurückgegangen ist, aber es ist dennoch entmutigend zu sehen, dass eine Schwachstelle, die schon vor dem Spiel DOOM auftrat, immer noch eine so große Bedrohung für die Landschaft darstellt. Die Wahrheit ist, dass ich nicht sehe, dass es viel besser wird. Während wir immer mehr Tools einführen, die uns helfen, schneller zu programmieren, verlieren die Entwickler den Bezug zu den grundlegenden Programmierprinzipien, und diese KI-Tools sind notorisch schlecht darin, anfälligen Code vorzuschlagen, einschließlich Injektionsschwachstellen.
Es ist jedoch nicht alles düster, denn wir sehen erhebliche Verbesserungen bei einer neuen Generation von SAST-Tools, die diese Schwachstellen viel effektiver aufspüren und beheben können und die Fähigkeit haben, die Bedrohungslandschaft drastisch zu verändern.
Ich melde mich jetzt ab und vergesse es nicht:
Entdecken und beheben Sie SQL-Injections automatisch mit Aikido AI SAST Autofix
Kasse Zen und verhindern Sie Injektionsangriffe, während sie passieren
Bonus: SQL-Geschichte im Laufe der Geschichte
Seit wir über die Sicherheit unserer Anwendungen sprechen, haben wir auch über SQL-Injektion gesprochen. In der allerersten OWASP-Top-10-Liste aus dem Jahr 2003 war sie sogar auf Platz 7 zu finden, 2010 wurde sie in die Kategorie Injektion aufgenommen und belegte bis 2021 Platz 1. Einer der ersten dokumentierten groß angelegten Angriffe mit SQL-Injection war der Angriff auf das Bekleidungsunternehmen Guess, bei dem Kreditkartennummern abgegriffen wurden. Seitdem ist SQL-Injection ein regelmäßiger Gast in den Sicherheitsschlagzeilen.
Bonus Teil 2 - Sehen Sie sich Injection Attacks 101 an, um eine Einführung in SQL Injections, Code Injections und XSS zu erhalten.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)