SQL-Injection und XSS: Wie die zwei klassischen Injection-Lücken entstehen und verhindert werden

SQL-Injection (SQLi) und Cross-Site-Scripting (XSS) sind die zwei ältesten und häufigsten Web-Schwachstellen. Sie wirken an verschiedenen Stellen, teilen aber eine Ursache: nicht vertrauenswürdige Nutzereingaben, die als Code/Query statt als Daten interpretiert werden. Diese gemeinsame Wurzel zu verstehen, klärt auch die richtige Abwehr.

SQL-Injection

SQLi entsteht, wenn Nutzereingaben direkt in eine Datenbankabfrage eingebettet werden. Baut die App:

"SELECT * FROM users WHERE email = '" + eingabe + "'"

ändert ein Angreifer mit ' OR '1'='1 die Logik der Abfrage — umgeht die Authentifizierung oder liest Daten aus. Die Auswirkung ist schwer: Lesen/Ändern von Daten, teils Codeausführung.

Abwehr — parametrisierte Abfragen: Die Ursache liegt darin, die Eingabe in den Abfragetext zu verketten. Parametrisierte Abfragen (Prepared Statements) tragen die Eingabe als separate Daten, die die Datenbank nie als Code interpretiert:

SELECT * FROM users WHERE email = ?   -- Eingabe als separater Parameter gebunden

Ergänzende Schichten: ein Datenbankkonto mit geringsten Rechten, Allowlist-Eingabevalidierung und die sicheren APIs von ORMs.

Cross-Site-Scripting (XSS)

XSS ist, wenn die Eingabe eines Angreifers als Skript in eine Seite gelangt und das JavaScript des Angreifers im Browser des Opfers ausführt. Drei Haupttypen:

• Reflected: Eingabe spiegelt sich sofort in der Antwort (z. B. Suchseite).
• Stored: Eingabe wird gespeichert und später anderen Nutzern serviert (z. B. Kommentarfeld) — am gefährlichsten.
• DOM-based: die Spiegelung geschieht im clientseitigen JavaScript.

Auswirkung: Diebstahl des Sitzungs-Cookies (ohne HttpOnly), Aktionen im Namen des Nutzers, Phishing, Defacement.

Abwehr — kontextbewusste Ausgabekodierung: Die Ursache wird behoben, indem Nutzerdaten je nach Kontext (HTML-Body, HTML-Attribut, JavaScript, URL) kodiert werden. Zusätzlich begrenzt eine Content-Security-Policy die Auswirkung von XSS, und HttpOnly verhindert Cookie-Diebstahl per Skript. Moderne Frameworks kodieren standardmäßig; nutzen Sie Kodierung umgehende Pfade vorsichtig.

Die gemeinsame Lehre

Beide löst dasselbe Prinzip: Daten aus Code-Kontexten heraushalten. Für SQLi leisten das parametrisierte Abfragen, für XSS kontextbewusste Ausgabekodierung.

Quellen: OWASP SQL Injection Prevention, OWASP XSS Prevention, OWASP Top 10: Injection.

Zeigt Ihre Site Anzeichen von Reflected XSS oder Injection? Die Active Verification von CyberTestify prüft das deterministisch mit harmlosen Prüfungen an erkannten Eintrittspunkten.