SQL-Injection entschlüsselt: Strategien für sichere Webanwendungen

SQL-Injection ist für Webentwickler seit ihrer ersten Entdeckung vor über 25 Jahren eine anhaltende Plage. Trotz ihres langen Bestehens zählt sie laut OWASP nach wie vor konstant zu den am häufigsten bewerteten Sicherheitslücken im Web. Diese einfachen Angriffe lassen sich zwar leicht verhindern, können aber großen Schaden anrichten und die Datenintegrität jeder mit einer Datenbank verbundenen Webanwendung gefährden.

Was ist SQL-Injection?

Bei einem SQL-Injection-Angriff handelt es sich um eine Variante von Injection-Angriffen, bei der Angreifer eine Webanwendung dazu bringen, in ihrem Namen SQL-Befehle direkt an die Datenbank zu übermitteln. So können Angreifer über Eingabedaten schädliche SQL-Abfragen einschleusen. Dadurch erhalten sie dieselben Zugriffsrechte wie die Anwendung und können die Datenbank von innen heraus abfragen und manipulieren.

Obwohl diese Angriffe als Angriffe auf Webanwendungen gelten, zielen sie tatsächlich auf die zugrunde liegenden Datenbanken ab, die die Website betreiben. Dadurch sind sämtliche in der Datenbank gespeicherten Daten dem Risiko ausgesetzt, offengelegt, verändert oder gelöscht zu werden. Das gefährdet die Datensicherheit und den Betrieb.

Wie funktioniert SQL-Injection?

Bei diesen Angriffen nutzen Angreifer Schwachstellen in Eingabefeldern von Webanwendungen aus. In der Regel geben Benutzer Daten über ein Formular ein. Nach einem Klick auf eine Schaltfläche verarbeitet die Anwendung die Eingabe. Für normale Benutzer ist das kein Problem: Die eingegebenen Daten bestehen meist nur aus Buchstaben oder Zahlen, die die Anwendung problemlos verarbeiten kann.

Problematisch wird es, wenn eine unzureichende Eingabevalidierung es ermöglicht, Zeichenfolgen einzufügen, die SQL-Befehle enthalten. Anders als gewöhnliche Eingaben veranlassen Sonderzeichen die Anwendung dazu, die normale Eingabe nicht weiterzuverarbeiten und stattdessen den angehängten Befehl auszuführen. Manchmal wird die resultierende Abfrage direkt auf dem Bildschirm angezeigt, sie kann aber auch im Hintergrund ablaufen. Solche Fälle werden als Blind-SQL-Injection-Angriffe bezeichnet. Auch wenn sie nicht immer sichtbare Antworten liefern, können sie erheblichen Schaden anrichten, etwa durch Änderungen an der Datenbank, und Angreifern so ermöglichen, den Angriff auszuweiten.

Wichtig ist jedoch: Nicht nur Formularfelder sind von solchen Angriffen betroffen. Jede Dateneingabe, die zu einer Interaktion mit einer Datenbank führt – etwa URL-Parameter oder direkte API-Aufrufe –, kann auf diese Weise kompromittiert werden, wenn keine angemessenen Schutzmaßnahmen vorhanden sind.

Beispiele für SQL-Injection-Angriffe

SQL-Hacking-Angriffe sind nicht komplex und gehören deshalb zum Standardrepertoire von Angreifern.

Alles beginnt mit einer einfachen SQL-Abfrage im Backend, wie der folgenden.

SELECT * FROM products WHERE name LIKE '%$searchTerm%';

In dieser Abfrage wird $searchTerm durch die Eingabe des Benutzers ersetzt. Gibt ein Benutzer beispielsweise „phone“ ein, führt der Server folgende Abfrage aus:

SELECT * FROM products WHERE name LIKE '%phone%';

Damit werden alle Produkte zurückgegeben, deren Name das Wort „phone“ enthält.

Sehen wir uns an, wie ein Angreifer dies mit einer SQL-Injection ausnutzen könnte. Angenommen, der Angreifer gibt ‘; DROP TABLE products; – ein. Dann ergibt sich folgende Abfrage:

SELECT * FROM products WHERE name LIKE '%'; DROP TABLE products; --%'

In diesem Szenario bewirkt die Injection Folgendes:

1. Die ursprüngliche Abfrage wird beendet: Der Teil ‘; schließt die ursprüngliche LIKE-Abfragebedingung.

2. Eine neue Abfrage wird eingeschleust: DROP TABLE products; ist eine neue SQL-Anweisung, die bei ihrer Ausführung die gesamte Produkttabelle löschen würde.

3. Der Rest wird auskommentiert: – kommentiert den verbleibenden Teil der Abfrage aus und verhindert so Syntaxfehler durch den Rest der ursprünglichen Abfrage (%’;).

Das Ergebnis: Der Angreifer kann den gesamten Inhalt der Produkttabelle löschen und damit alle Daten vernichten, ohne über legitime Zugriffsrechte auf die Datenbank zu verfügen. Dies ist nur eine Variante, diese Sicherheitslücke auszunutzen. Mit komplexeren Versionen lässt sich der Prozess nutzen, um Rechte auszuweiten oder Daten aus der Tabelle zu exfiltrieren.

Die Gefahren von SQL-Injection

Das offensichtlichste Risiko von SQL-Injection-Angriffen ist, dass vertrauliche Informationen über den Browser offengelegt werden. Die meisten Anwendungen verfügen über Kontrollen, die den Datenzugriff von Benutzern einschränken. SQL-Injection-Angriffe ermöglichen es Angreifern, diese Kontrollen zu umgehen und die Datenbank wie die Anwendung abzufragen. Je nach Art der offengelegten vertraulichen Daten kann ein solcher Datenschutzverstoß rechtliche und Compliance-Strafen nach sich ziehen.

Die Risiken dieser Angriffe gehen jedoch weit über den Verlust von Daten hinaus: Die erweiterten Zugriffsrechte lassen sich auch dazu nutzen, Daten auf dem Datenbankserver zu ändern oder zu löschen. Einfallsreiche Angreifer können damit Informationen in der Benutzertabelle ändern und den Benutzernamen sowie das Passwort eines Benutzers ändern. So können sie sich als legitime Anwendungsbenutzer mit erweiterten Rechten ausgeben und Angriffe durchführen, ohne Alarme auszulösen. Mit dieser Angriffsmethode lassen sich möglicherweise auch die internen Datenbankberechtigungen ins Visier nehmen, um Datenbankbenutzer und ihre Berechtigungen zum direkten Anmelden an der Datenbank zu erstellen oder zu ändern.

So verhindern Sie SQL-Injection

SQL-Injection bedroht die Sicherheit von Webanwendungen schon so lange, weil ihre Verhinderung eine mehrschichtige Strategie erfordert. Die erste Schutzschicht umfasst die Eingabevalidierung und -bereinigung: Dabei werden Zeichen entfernt, mit denen SQL-Anweisungen verlassen oder andere Injection-Angriffe ermöglicht werden könnten. Das Risiko einer Injection sinkt erheblich, wenn sämtliche Benutzereingaben gründlich geprüft und von potenziell schädlichen Daten bereinigt werden.

Darauf aufbauend kommen parametrisierte Abfragen und vorbereitete Anweisungen zum Einsatz. Diese sicheren Programmierpraktiken trennen die SQL-Logik wirksam von den Benutzereingaben und neutralisieren so die Risiken dynamisch generierter Abfragen.

Die letzte Schutzschicht bilden regelmäßige Sicherheitsaudits und Tests, mit denen überprüft wird, ob die bestehenden Kontrollen diese Angriffe wirksam verhindern. Mithilfe automatisierter Tools können Unternehmen ihre Anwendungen auf Schwachstellen prüfen und Bereiche identifizieren, in denen die Bereinigung nicht ausreicht, um solche Angriffe zu verhindern.

SQL-Injection-Angriffe mit Snyk proaktiv stoppen

Für die Entwicklung sicherer Anwendungen benötigen Sie Tools, die Schwachstellen präzise erkennen. Snyk API & Web überzeugt in diesem Bereich und erkennt über 30.000 potenzielle Schwachstellen, darunter kritische wie Cross-Site-Scripting (XSS) und SQL-Injections.

Snyk API & Web wurde dafür entwickelt, potenzielle Sicherheitsprobleme proaktiv aufzudecken und zu beheben, indem es sich nahtlos in Entwicklungs-Workflows integrieren lässt. Diese Integration vereinfacht den Prozess und ermöglicht automatisierte, kontinuierliche Sicherheitsbewertungen, die die Effizienz steigern. Mit Snyk API & Web können Entwickler ihre Anwendungen in jeder Phase des Entwicklungslebenszyklus stärken und sicherstellen, dass sie die vertraulichsten Daten Ihres Unternehmens zuverlässig schützen.

Erfahren Sie, wie Snyk API & Web Sie beim Schutz Ihrer Anwendungen unterstützt, und buchen Sie eine Live-Demo.

Häufig gestellte Fragen

Welche Rolle spielt eine Web Application Firewall (WAF) bei der Verhinderung von SQL-Injection?

Eine WAF hilft dabei, SQL-Injection-Versuche zu überwachen und zu filtern, und bietet so eine zusätzliche Sicherheitsebene für Webanwendungen.

Können NoSQL-Datenbanken von SQL-Injection betroffen sein?

Auch wenn sich die Syntax unterscheidet, können NoSQL-Datenbanken für Injection-Angriffe anfällig sein – insbesondere bei unzureichend bereinigten Eingaben.

Ist SQL-Injection nur für Websites mit Login-Seiten ein Risiko?

Nein, jeder Bereich einer Website, der mit einer Datenbank interagiert, kann potenziell für SQL-Injection anfällig sein – nicht nur Login-Seiten.