Input-Validierung und Sanitizing
Fast alle Injektionsangriffe – SQL-Injection, XSS, Command-Injection, Path-Traversal – haben eine gemeinsame Ursache: Nutzereingaben werden unkritisch verarbeitet. Input-Validierung prüft, ob eine Eingabe das erwartete Format hat. Sanitizing bereinigt oder kodiert die Eingabe, damit sie nicht als Befehl interpretiert werden kann.
Der wichtigste Grundsatz: Never trust user input. Alles, was von außen kommt – Formularfelder, URL-Parameter, HTTP-Header, API-Payloads, Datei-Uploads – kann manipuliert sein. Client-seitige Validierung (JavaScript im Browser) ist nützlich für Benutzerkomfort, aber kein Sicherheitsmerkmal: Ein Angreifer sendet Requests direkt an den Server, ohne den Browser zu nutzen. Alle Sicherheitsprüfungen müssen server-seitig stattfinden.
1) Validierungs-Playground
Der folgende Playground simuliert server-seitige Validierungslogik für verschiedene Input-Typen. Probiere verschiedene Eingaben aus und sieh, wie der Server reagiert.
2) Validierung, Sanitizing, Escaping – die drei Konzepte
Die drei Konzepte werden oft verwechselt oder synonym verwendet, haben aber unterschiedliche Rollen im Sicherheitsmodell.
3) Whitelist vs. Blacklist
Es gibt zwei grundsätzlich verschiedene Ansätze zur Validierung: Erlaubtes definieren (Whitelist) oder Verbotenes ausschließen (Blacklist). Der Unterschied ist sicherheitskritisch.
Zusammenfassung
| Grundsatz | Bedeutung |
|---|---|
| Never trust user input | Alle Eingaben von außen als potenziell böswillig behandeln |
| Server-seitig validieren | Client-seitige Validierung ist kein Sicherheitsmerkmal |
| Whitelist bevorzugen | Erlaubtes definieren statt Verbotenes ausschließen |
| Kontextgerechtes Escaping | HTML-, SQL-, Shell-, URL-Encoding je nach Ausgabekontext |
| Defense in Depth | Validierung + Sanitizing + Escaping kombinieren |