Tipps eines Pentesters zum Thema Datenvalidierung

Input-Validierung muss immer auf der Serverseite passieren. Alles, was auf der Clientseite gemacht wird, kann grundsätzlich umgangen werden. Wird z.B. JavaScript zur Input-Validierung verwendet, reicht es schon einen simplen Script Blocker zu verwenden.

Weiters können Angreifer einen Web Interception Proxy verwenden, um generierte HTTP Requests abzufangen und zu ändern. Auch damit lässt sich clientseitige Validierung umgehen.

Grundsätzlich spricht nichts dagegen, die Datenvalidierung zusätzlich clientseitig durchzuführen. Dadurch kann vermieden werden, dass der Server viele falsch formatierte Requests ablehnen muss und der Benutzer sämtliche Daten erneut eingeben muss. Hierbei handelt es sich aber rein um ein Usability Feature, und nicht um ein Security-Feature.

Also kurz:
Clientseite = Usability
Serverseite = Security

Diesen Grundsatz sollte man immer im Hinterkopf behalten. Erwarten Sie nicht, dass Daten richtig formatiert sind, selbst dann, wenn sie aus einer scheinbar vertrauenswürdigen Quelle kommen.

Sämtliche Eingangsdaten müssen validiert werden, seien es Daten, die von einem Interface kommen, aus Konfigurations-Dateien, aus der Datenbank etc.

Selbst wenn die Daten von einem selbst geschriebenen Programm generiert werden, empfiehlt es sich sie trotzdem zu validieren.

Schlägt ein Validierungs-Schritt fehl, soll der gesamte Inhalt abgelehnt werden. Wir empfehlen nicht zu versuchen, falschen Input in richtigen Input umzuwandeln, da der Code, der diese Umwandlung durchführt, ebenso von Angreifern missbraucht werden kann.

Ein häufiger Fehler ist es, Blacklists für die Datenvalidierung zu verwenden. Eine Blacklist oder Block List beinhaltet alle Zeichen (und Zeichenketten), die nicht erlaubt sind.

Das Problem dabei ist, dass eine Blacklist fast nie komplett ist. Oft finden Angreifer Möglichkeiten, eine Blacklist zu umgehen, z.B. indem verbotene Zeichen kodiert werden.

Eine Whitelist oder Allow List beinhaltet sämtliche Werte, die erlaubt sind. Alle anderen Werte werden standardmäßig abgelehnt. Ein solches System lässt sich kaum umgehen.

Für strukturierte Daten gibt es die Möglichkeit, eine Whitelist Regular Expression zu erzeugen, die angibt, welche Zeichen verwendet werden dürfen, und welche Länge der Input haben muss.

Es gibt zwei verschiedene Arten, wie Daten validiert werden können.

Bei der syntaktischen Datenvalidierung geht es darum, dass Daten die korrekte Syntax, also Struktur, aufweisen. Zum Beispiel ist eine Sozialversicherungsnummer immer eine zehnstellige Zahl. Auch Datumsfelder und E-Mail-Adressen weisen immer eine bestimmte Struktur auf, die überprüft werden kann. Hierzu eigen sich zum Beispiel Regular Expressions.

Bei der semantischen Datenvalidierung geht es darum, die Datenwerte im jeweiligen Kontext zu überprüfen. Handelt es sich bei einem Eingabefeld zum Beispiel um ein Geburtsdatum, so kann dieses nicht in der Zukunft liegen.

Um die beste Sicherheit zu gewährleisten, muss natürlich die Syntax und die Semantik validiert werden.

Ein wichtiger Mitspieler für die Datenvalidierung ist das Output Encoding. Grundsätzlich kann nicht jedes „böse“ Zeichen als Eingabe verboten werden.

Will man z.B. XSS vermeiden, aber Symbole wie sollen erlaubt sein, wird Output Encoding benötigt.

Wie ein Zeichen kodiert werden muss, hängt immer vom jeweiligen Kontext ab. So können spitze Klammern in einem HTML Kontext z.B. mittels HTML Entities kodiert werden (& lt ; gt ;). Im HTTP Kontext müssen Zeichen kodiert werden, die in URLs nicht erlaubt sind. So kann man etwa das & Symbol mittels URL Encoding als %26 darstellen.

Weitere Beispiele für gängige Kodierungen sind ASCII und UNICODE für Text, und Base64 für Binärdaten.