Eingabevalidierung und Ausgabekodierung

Injection-Schwachstellen — SQL-, Command-, LDAP-, XPath-Injection und weitere — entstehen, wenn nicht vertrauenswürdige Eingaben als Code interpretiert werden. Die Eingabevalidierung stellt sicher, dass Daten erwarteten Typen, Längen und Formaten entsprechen, bevor sie verarbeitet, gespeichert oder zurückgegeben werden.

Die Allowlist- (Whitelist-)Validierung definiert, was akzeptabel IST: nur alphanumerische Zeichen, nur Ganzzahlen im Bereich von 1–100, nur gültige E-Mail-Formate. Eine Denylist (Blacklist) versucht, bekannte schädliche Eingaben zu blockieren, ist aber immer unvollständig. Bevorzugen Sie Allowlists.

Clientseitige Validierung verbessert die Benutzerfreundlichkeit, bietet aber keinerlei Sicherheit — Angreifer umgehen sie problemlos mit Browser-Entwicklertools oder curl. Validieren Sie immer auf der Serverseite. Clientseitige Validierung ist eine Komfortfunktion; serverseitige Validierung ist die Sicherheitskontrolle.

Zahlen: Prüfen Sie Typ und Wertebereich. Zeichenketten: Prüfen Sie Länge und Zeichensatz. Datumsangaben: Parsen Sie sie strikt und prüfen Sie den Wertebereich. Dateien: Prüfen Sie Erweiterung UND Magic Bytes/MIME-Typ — vertrauen Sie niemals allein auf die Erweiterung. URLs: Parsen und validieren Sie Schema, Host und Pfadkomponenten.

Die wichtigste Maßnahme bei der Eingabevalidierung für Datenbanken besteht darin, Benutzereingaben niemals mit SQL zu verketten. Verwenden Sie parametrisierte Abfragen (Prepared Statements), bei denen Benutzereingaben als Parameter und nicht in die Abfragezeichenfolge interpoliert übergeben werden.

Für dieselbe Zeichenkette ist je nach Kontext ein anderes Encoding erforderlich. HTML-Body: HTML-Encoding (< > &). HTML-Attribut: HTML-Attribut-Encoding. JavaScript: JS-Escaping. URL-Parameter: URL-Encoding (Percent-Encoding). Falsches Encoding hinterlässt Lücken, die Angreifer ausnutzen können.

Fügen Sie Benutzerdaten niemals direkt in HTML ein. Verwenden Sie eine Template-Engine oder Bibliothek, die HTML automatisch escaped. In React ist {value} sicher; dangerouslySetInnerHTML umgeht das Escaping. In Django maskieren Templates automatisch, sofern Sie nicht ausdrücklich den safe-Filter verwenden.

Beim Einfügen von Daten in JavaScript (z. B. in eine mit Benutzerdaten initialisierte Variable) reicht HTML-Encoding nicht aus. Verwenden Sie JSON-Encoding: JSON.stringify(value). Dadurch wird verhindert, dass Daten aus dem Kontext eines JS-String-Literals ausbrechen.

In URLs eingefügte, vom Benutzer bereitgestellte Daten müssen mit encodeURIComponent() (JS) oder urllib.parse.quote() (Python) per Percent-Encoding kodiert werden. Nicht kodierte Daten können die URL-Struktur manipulieren und dadurch zu Open Redirects oder Path Traversal führen.

CSP bietet eine zweite Verteidigungslinie gegen XSS. Eine strikte CSP mit Nonces verhindert die Ausführung von Inline-Skripten selbst dann, wenn eine XSS-Payload eingeschleust wird, da der Browser die Ausführung von Skripten ohne das korrekte nonce-Attribut verweigert.

DOM-XSS tritt auf, wenn JavaScript aus angreifergesteuerten Quellen (location.hash, document.URL, cookie) liest und in gefährliche Senken (innerHTML, document.write, eval) schreibt. Prüfen Sie alle Datenflüsse von Browser-APIs zu DOM-Senken mithilfe statischer Analysetools.

Warum ist serverseitige Eingabevalidierung auch dann unverzichtbar, wenn clientseitige Validierung implementiert wurde?

Eingabevalidierung (Allowlists, Typprüfung, Längenbegrenzungen) in Kombination mit kontextsensitivem Output-Encoding (HTML, JS, URL, SQL-Parametrisierung) stellt die wichtigste Verteidigung gegen Injection- und XSS-Angriffe dar. Beides muss ausnahmslos serverseitig angewendet werden.