Skip to content
NeuralSkills
Sicherheit

SQL-Injection-Verhinderer

SQL-Injection-Schwachstellen in der Codebasis erkennen und parametrisierte Abfragen, ORMs und Eingabevalidierung implementieren.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

SQL Injection bleibt nach Jahrzehnten des Bewusstseins die gefaehrlichste und am haeufigsten ausgenutzte Schwachstellenklasse. Entwickler verketten immer noch Nutzereingaben in Query-Strings, verwenden dynamische Tabellennamen ohne Whitelisting oder vertrauen ORM-Abstraktionen, die still auf Raw Queries zurueckfallen. Ein einziger injizierbarer Endpunkt kann die gesamte Datenbank offenlegen — Kundendaten, Zahlungsinformationen, Admin-Zugangsdaten — in wenigen Minuten.

Der Prompt

Du bist ein Datenbank-Sicherheitsspezialist. Analysiere den folgenden Code auf SQL-Injection-Schwachstellen, einschliesslich Second-Order-Injection, Blind Injection und ORM-Bypass-Muster.

SPRACHE/ORM: [z.B. Node.js/Knex, Python/SQLAlchemy, PHP/PDO, Java/Hibernate]
DATENBANK: [z.B. PostgreSQL, MySQL, SQLite, MSSQL]

CODE:
[Datenbankinteraktionscode einfuegen — Abfragen, Modelle, Repositories, Stored Procedures]

Fuer jeden Befund:
1. **Injection-Typ**: Klassisch / Blind / Second-Order / UNION-basiert / Zeitbasiert
2. **Angriffsvektor**: Exakter Payload eines Angreifers
3. **Auswirkung**: Auf welche Daten zugegriffen oder was veraendert werden kann
4. **Verwundbarer Code**: Genaue Zeile mit dem Fehler
5. **Sichere Alternative**: Parametrisierte Abfrage oder ORM-Aequivalent

Zusaetzlich pruefen:
- Dynamische Tabellen-/Spaltennamen aus Nutzereingaben
- LIKE-Klauseln ohne Wildcard-Escaping
- ORDER BY mit nutzergesteuerten Spaltennamen
- Raw-Query-Methoden im ORM-Code (z.B. .raw(), execute())
- Stored Procedures mit dynamischem SQL (EXEC, sp_executesql)
- JSON/NoSQL-Injection in hybriden Abfragen

Am Ende eine sichere Coding-Checkliste spezifisch fuer [SPRACHE/ORM] bereitstellen.

Beispielausgabe

## SQL-Injection-Audit: 4 Schwachstellen gefunden

### KRITISCH: Klassische SQL Injection
Zeile 34: `db.query(\`SELECT * FROM users WHERE email = '\${email}'\`)`
Payload: `' OR '1'='1' --` liefert alle Nutzer zurueck.
Loesung: `db.query('SELECT * FROM users WHERE email = $1', [email])`

### HOCH: ORDER BY Injection
Zeile 67: `query += \` ORDER BY \${req.query.sort}\``
Payload: `sort=1;DROP TABLE users--` fuehrt beliebiges SQL aus.
Loesung: Erlaubte Spalten whitelisten: `const allowed = ['name','date']; const col = allowed.includes(sort) ? sort : 'name'`

Wann verwenden

Bei jeder Datenbankzugriffsschicht vor dem Deployment ausfuehren, besonders nach dem Hinzufuegen neuer API-Endpunkte oder Suchfunktionen. Kritisch bei ORM-Migrationen, Datenbanktreiber-Upgrades oder der Einfuehrung von Volltextsuche. Immer dann einsetzen, wenn ein Entwickler eine Raw-SQL-Abfrage statt des ORM Query Builders schreibt.

Profi-Tipps

  • Mit echten Payloads testen — die KI nach SQLMap-kompatiblen Payloads fuer jeden Befund fragen, um den tatsaechlichen Exploitation-Pfad zu verstehen.
  • ORM-Escape-Hatch pruefen — jedes ORM hat Raw-Query-Methoden (.raw(), execute(), $queryRaw), die eingebaute Schutzfunktionen umgehen. Zuerst danach suchen.
  • Stored Procedures einbeziehen — serverseitiges SQL mit dynamischer Verkettung ist genauso verwundbar wie Anwendungscode.
  • Second-Order-Injection beachten — Daten werden sicher gespeichert, aber spaeter unsicher verwendet (z.B. Nutzername korrekt gespeichert, aber in einem Report-Query injiziert).