SQL-Injection ohne Mythen: So finden und beheben Sie sie im Projekt
Ein praxisnaher Leitfaden zu SQL-Injection: Funktionsweise, typische Fundstellen im Code, riskante Muster in Sprachen und Frameworks, Teststrategien sowie hilfreiche Tools und Bibliotheken.
Kurz erklärt
Nehmen wir eine Produktsuche. Die Anwendung möchte SELECT * FROM products WHERE name = ? ausführen. Bei einem Parameter erhält die Datenbank Abfragevorlage und Wert getrennt. Verkettet ein Entwickler den String manuell, kann die Eingabe die Struktur von WHERE verändern, eine Bedingung ergänzen oder den Befehl beenden.
Der Benutzer kontrolliert einen Wert
Das kann ein Query-String, JSON-Body, Cookie, Header, CSV-Import, Webhook, Sortierparameter oder eine Queue-Nachricht sein. Wenn eine externe Partei die Quelle verändern kann, behandeln Sie sie als nicht vertrauenswürdig.
Der Wert wird mit SQL verbunden
Das Risiko entsteht bei query = '... ' + input + ' ...', Template Strings, Raw Query Buildern oder ORM-Methoden, die fertiges SQL akzeptieren. Eine Formatprüfung ersetzt keine Parametrisierung.
Die Datenbank sieht Syntax statt Daten
Sonderzeichen und SQL-Fragmente können Bedingungen ändern, Ergebnisse verbinden, die Antwortzeit beeinflussen oder eine Leseoperation in eine Schreiboperation verwandeln — abhängig von Treiber und Rechten.
Der Fehler reicht über einen Endpoint hinaus
Hat der Connection User zu viele Rechte, kann ein kompromittierter Endpoint Tabellen, Reports, personenbezogene Daten, Backups oder Datensätze anderer Tenants gefährden.
Mentales Modell
Fragen Sie nicht nur, ob das Projekt ein ORM verwendet. Fragen Sie, ob externe Eingaben die SQL-Struktur beeinflussen können und mit welchen Rechten die Abfrage ausgeführt wird.
Diese Zahlen müssen korrekt eingeordnet werden. OWASP misst die breite Kategorie Injection, zu der SQLi, XSS und weitere CWEs gehören. MITRE bewertet CWE-89 anhand von CVE-Daten. Das ist weder der Anteil aller Angriffe noch ein Ranking von Programmiersprachen.
274.228
Vorkommen der Kategorie Injection im OWASP-Datensatz; die durchschnittliche Incidence Rate lag bei 3,37 %. [2]
Nr. 2
SQL Injection belegte in MITREs CWE Top 25 für 2025 den zweiten Platz mit einem Score von 28,72. [3]
94 %
der Anwendungen in der Untersuchung wurden auf irgendeine Form von Injection getestet. [2]
Was das für ein Team bedeutet
SQLi ist ein gut beschriebenes, reifes Problem. Das macht Legacy-Code aber nicht automatisch sicher. Die wiederkehrenden Muster helfen bei der Verteidigung, weil sie sich mit statischer Analyse und Tests prüfen lassen.
Beginnen Sie mit dem Data Flow, nicht mit einer Framework-Liste: Finden Sie die externe Quelle, verfolgen Sie sie bis zur Data-Access-Schicht und prüfen Sie den tatsächlichen Treiberaufruf.
Gefährliche Sinks finden
Suchen Sie nach query, execute, raw, text, literal, sequelize.query, knex.raw, jdbc.Statement, SqlCommand und Äquivalenten. Prüfen Sie, ob sie einen verketteten String erhalten.
Dynamisches SQL prüfen
Achten Sie besonders auf ORDER BY, Spalten-/Tabellennamen, Report Builder und Filter. Bind-Variablen können Identifier oft nicht repräsentieren; nutzen Sie stattdessen ein Allow-List-Mapping aus festen Werten. [1]
ORM-Auswege untersuchen
Prüfen Sie Raw SQL, unsichere Operatoren, Custom Scopes, String-Filter und Migrationen. Ein ORM senkt das Risiko nur, wenn das Team seine parametrisierte API nutzt.
Nicht offensichtliche Einstiegspunkte einbeziehen
Admin-Oberflächen, Imports, Cronjobs, Integrationen, GraphQL-Resolver, Such-Endpoints und interne APIs verarbeiten ebenfalls Daten, die zuvor in der Kette manipuliert worden sein können.
Fehlerbehandlung prüfen
SQL-Stacktraces, Tabellen- oder Treibernamen und unterschiedliche Fehler erleichtern die Diagnose eines Angriffs. Nach außen gehört eine sichere Fehlermeldung; Details bleiben in Correlation-ID-Logs.
Es gibt kein seriöses Ranking der gefährlichsten Sprache: SQLi ist überall möglich, wo SQL auf eine unsichere API trifft. Der Unterschied liegt darin, wie leicht man versehentlich vom parametrisierten Weg zu Raw SQL wechselt.
| Ökosystem | Typischer Risikopunkt | Sicherer Default | Was prüfen |
|---|---|---|---|
| PHP: Laravel / Symfony | DB::raw, Query Strings, alter mysqli/PDO-Code | Query Builder/Eloquent Bindings, PDO Prepared Statements | raw(), gebundene Parameter, Legacy-Controller |
| JavaScript / TypeScript: Node.js | pg/mysql2 Template Strings, knex.raw, Sequelize raw | Driver-Placeholders, Prisma-Parameter, Query Builder | $queryRawUnsafe, raw(), dynamische Filter |
| Python: Django / SQLAlchemy | cursor.execute-Konkatenation, text() mit String | Django QuerySet, gebundene SQLAlchemy-Parameter | extra(), raw(), Literal-SQL, f-Strings |
| Java: Spring / Hibernate | Statement, String-Konkatenation, HQL-Interpolation | PreparedStatement, JPA-Parameter, Named Parameters | createNativeQuery, HQL-Interpolation |
| .NET: ASP.NET / EF Core | FromSqlRaw oder SqlCommand mit String | LINQ, FromSqlInterpolated, Parameter | Raw-Methoden, interpoliertes SQL, Datenbankrolle |
| Go / Rust | database/sql oder Client-APIs mit String-Aufbau | QueryContext/Execute-Placeholders, sqlx-Bind | fmt.Sprintf, format!, dynamische Identifier |
Das Fazit zum Stack
Das größte Risiko kommt nicht von einer Sprache, sondern von Teams, die Input mit Query-Text vermischen, Raw SQL ohne Review erlauben oder der Anwendung eine DBA-Rolle geben.
Unsicher: Der String weiß zu viel
const sql = `SELECT * FROM users WHERE email = '${email}'`;
const result = await db.query(sql);Hier wird email Teil des SQL-Texts. Auch wenn das zunächst nur eine Suche ist, wird dieses Muster leicht in Login-, Export- oder Admin-Funktionen kopiert.
Sicherer: Der Treiber trennt Werte
const result = await db.query(
"SELECT * FROM users WHERE email = $1",
[email],
);Der Query-Text bleibt fest und email wird als Wert übergeben. Die Placeholder-Syntax hängt vom Treiber ab — folgen Sie der Dokumentation Ihrer Client-Bibliothek.
Für Sortierfelder: Mapping statt Bind
const columns = { newest: "created_at", price: "price" } as const;
const column = columns[input] ?? columns.newest;
const sql = `SELECT * FROM products ORDER BY ${column}`;Spaltennamen sind keine normalen Bind-Werte. Erlauben Sie nur Schlüssel aus einer festen Liste und setzen Sie niemals Raw Input direkt ein.
Kein einzelnes Tool sieht das gesamte Bild. Der stärkste Workflow kombiniert Code-Analyse, Endpoint-Tests und Runtime-Beobachtung.
CodeQL
SAST zur Verfolgung von User Input bis zu SQL-Sinks in JavaScript/TypeScript, Python, Java, C# und weiteren unterstützten Sprachen. In CI integrieren und Findings mit dem Code Owner prüfen.
Semgrep
Schnelle Pattern- und Data-Flow-Regeln für lokale Checks und Pre-Commit. Damit lassen sich konkrete unsichere Aufrufe wie Raw Queries ohne Parameter verbieten.
Burp Suite / OWASP ZAP
DAST für Staging: Proxy, Request-Replay sowie aktive und passive Scans. Nur mit freigegebenem Scope arbeiten und keine destruktiven Checks gegen Production ausführen.
PortSwigger Web Security Academy
Eine sichere Lernumgebung mit SQLi-Labs zu Error-Based, Blind, UNION und weiteren Szenarien. Das Team kann üben, ohne Kundendaten zu berühren.
Sentry / DB-Audit-Logs / WAF
Achten Sie auf ungewöhnliche 4xx/5xx-Spitzen, Latenz, SQL-Parserfehler, Massen-SELECTs, auffällige User-Agents und ungewöhnliche Tabellenzugriffe. Ein WAF reduziert Risiko, ersetzt aber keinen Code-Patch.
OWASP empfiehlt mehr als einen Filter. Bauen Sie eine Defense-in-Depth-Baseline auf und machen Sie sie zum Bestandteil der Definition of Done.
Parametrisierte Abfragen oder sichere Stored Procedures verwenden; dynamisches SQL braucht eine Allow-List und ein separates Review. [1]
Escaping nicht als primären Schutz verwenden: OWASP bezeichnet es als fragil und empfiehlt es nur als letzten Ausweg für Legacy-Code. [1]
Einen eigenen Datenbankbenutzer mit minimalen SELECT/INSERT/UPDATE-Rechten verwenden, niemals eine DBA-/Owner-Rolle. Read-only Flows bekommen Read-only Accounts oder Views. [1]
Keine Secrets oder Produktionsdaten loggen. Endpoint, Actor, Request-ID und Policy-Ergebnis erfassen, aber kein vollständiges SQL mit personenbezogenen Parametern.
Negative Tests ergänzen: Anführungszeichen in legitimen Namen, lange Strings, Unicode, falsche Typen, unbekannte Sortierschlüssel, Cross-Tenant-IDs und Grenzwerte.
Treiber, ORM und Datenbank aktuell halten, Updates aber nicht mit sicherem Query-Aufbau verwechseln.
Erste Stunde
Schaden begrenzen
Endpoint, Zeitpunkt, Request-ID und Scope sichern. Bei Bedarf Feature deaktivieren, Route einschränken oder die Datenbankrolle auf Read-only reduzieren. Logs nicht löschen und nicht in Production experimentieren.
Am selben Tag
Root Cause beheben
String-basiertes SQL durch eine parametrisierte API ersetzen, Allow-List-Mapping für Identifier ergänzen, Rechte prüfen und einen Regressionstest schreiben, der gegen die alte Implementierung fehlschlägt.
Nach dem Patch
Blast Radius prüfen
Datenbank-Audit-Logs, ungewöhnliche Exporte, Datenänderungen, Service Accounts und Zugriffe auf andere Tenants prüfen. Dokumentieren, was gelesen oder verändert worden sein könnte.
Vor dem Abschluss
Prozess verbessern
SAST/DAST in CI, eine Review-Regel für Raw Queries, eine Least-Privilege-Migration und ein kurzes Incident-Playbook ergänzen. Sonst taucht die nächste SQLi an einem anderen Endpoint auf.
ORMs parametrieren Standardabfragen meistens, schützen aber nicht automatisch vor Raw SQL, unsicheren Operatoren, dynamischen Identifiern oder eigenen Query Buildern. Prüfen Sie Escape Hatches und Team-Regeln.
Formatvalidierung hilft, ist aber kein universeller Schutz. Verwenden Sie parametrisierte Abfragen für Werte und feste Allow-List-Mappings für Tabellen, Spalten und Sortierung.
Ja. GraphQL verändert die API-Form, aber ein Resolver kann Argumente weiterhin in unsicheres SQL, Filter oder Raw Queries übergeben. Verfolgen Sie den Data Flow vom Resolver bis zum Datenbank-Client.
Ein WAF kann bekannte Muster blockieren und die Ausnutzung reduzieren, behebt aber keinen unsicheren Query-Aufbau und deckt nicht garantiert jede Verschleierung oder Business-Route ab. Patch, Least Privilege und Tests bleiben nötig.
Nutzen Sie eine lokale Sandbox, OWASP Juice Shop, WebGoat oder PortSwigger Academy. Testen Sie niemals fremde Websites, Kunden-APIs oder Production-Systeme ohne ausdrücklich freigegebenen Scope.
PAS7 Studio kann API, Admin-Oberfläche und Data-Access-Layer prüfen: Raw SQL finden, Tenant-Grenzen testen, SAST/DAST in CI konfigurieren, Datenbankrechte reduzieren und einen priorisierten Behebungsplan erstellen.
Verwandte Artikel
AI Assistant Entwicklung Kosten 2026: RAG, Knowledge Base, Integrationen und Support
Praktischer Leitfaden zu Kosten fuer AI Assistants: RAG, Knowledge Base, Channels, Tool Use, Guardrails, Evaluations, Monitoring und Support.
AI-assisted Attacks und Prompt Injection 2026: neue Angriffsfläche für AI-Produkte
AI-assisted Attacks und Prompt Injection 2026: neue Angriffsfläche für AI-Produkte. Ein praktischer PAS7-Studio-Sicherheitsleitfaden mit Threat Model, Kontrollen, Rollout-Checklist, Fehlern und Quellen.
KI fur Landingpage-Entwicklung: wo sie Launches beschleunigt und wo sie Conversion schadet
Eine praxisnahe Analyse zur Nutzung von KI fur Landingpages: v0, Webflow AI, Builder.io, Framer-ahnliche Builder, UX-Generierung, Copy, SEO, Personalisierung, A/B-Tests, Template-Risiken, Accessibility, Security und technischer Schuldenaufbau.
AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents
Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.
Professionelle Entwicklung für Ihr Geschäft
Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.