Auswirkung von SQL-Injection
SQL-Injection (SQLi) ermöglicht es einem Angreifer, in die Abfragen einzugreifen, die eine Anwendung an ihre Datenbank [S1] stellt. Die primäre Auswirkung umfasst den unbefugten Zugriff auf sensible Daten wie Benutzerkennwörter, Kreditkartendaten und persönliche Informationen [S1].
Über den Datendiebstahl hinaus können Angreifer häufig Datenbankeinträge ändern oder löschen, was zu dauerhaften Änderungen im Anwendungsverhalten oder Datenverlust [S1] führt. In Fällen mit hohem Schweregrad kann SQLi eskaliert werden, um die Back-End-Infrastruktur zu gefährden, Denial-of-Service-Angriffe zu ermöglichen oder eine dauerhafte Hintertür in die Systeme der Organisation bereitzustellen [S1][S2].
Grundursache: Unsichere Eingabeverarbeitung
Die Hauptursache der SQL-Injection ist die unsachgemäße Neutralisierung spezieller Elemente, die in einem SQL-Befehl [S2] verwendet werden. Dies tritt auf, wenn eine Anwendung SQL-Abfragen erstellt, indem sie extern beeinflusste Eingaben direkt in der Abfragezeichenfolge [S1][S2] verkettet.
Da die Eingabe nicht ordnungsgemäß von der Abfragestruktur isoliert ist, führt der Datenbankinterpreter möglicherweise Teile der Benutzereingabe als SQL-Code aus, anstatt sie als Literaldaten [S2] zu behandeln. Diese Sicherheitslücke kann sich in verschiedenen Teilen einer Abfrage manifestieren, einschließlich SELECT-Anweisungen, INSERT-Werten oder UPDATE-Anweisungen [S1].
Konkrete Korrekturen und Abhilfemaßnahmen
Verwenden Sie parametrisierte Abfragen
Der effektivste Weg, SQL-Injection zu verhindern, ist die Verwendung parametrisierter Abfragen, auch bekannt als vorbereitete Anweisungen [S1]. Anstatt Zeichenfolgen zu verketten, sollten Entwickler strukturierte Mechanismen verwenden, die die Trennung von Daten und Code [S2] erzwingen.
Prinzip der geringsten Privilegien
Anwendungen sollten sich mit den niedrigsten Berechtigungen, die für ihre Aufgaben erforderlich sind, mit der Datenbank verbinden [S2]. Ein Webanwendungskonto sollte keine Administratorrechte haben und auf die spezifischen Tabellen oder Vorgänge beschränkt sein, die für seine Funktion [S2] erforderlich sind.
Eingabevalidierung und Kodierung
Die Eingabevalidierung ist zwar kein Ersatz für die Parametrisierung, bietet aber eine tiefgreifende Verteidigung [S2]. Anwendungen sollten eine „Akzeptieren-als-gut“-Strategie verwenden, um zu überprüfen, ob die Eingabe den erwarteten Typen, Längen und Formaten entspricht [S2].
Wie FixVibe darauf testet
FixVibe deckt bereits die SQL-Injection über das geschlossene active.sqli-Scannermodul ab. Aktive Scans werden erst nach der Überprüfung und Bescheinigung des Domänenbesitzes ausgeführt. Die Prüfung durchsucht GET-Endpunkte gleichen Ursprungs mit Abfrageparametern, erstellt eine Basisantwort, sucht nach SQL-spezifischen booleschen Anomalien und meldet einen Befund erst nach zeitlicher Bestätigung über mehrere Verzögerungslängen hinweg. Repository-Scans helfen auch dabei, die Grundursache früher zu erkennen, indem code.web-app-risk-checklist-backfill unformatierte SQL-Aufrufe kennzeichnet, die mit Vorlageninterpolation erstellt wurden.