It’s #FrontendFriday – Visual Spoofing und Validierung
„Ist das ein kleines L oder ein großes i?“ – viele kennen bestimmt diesen Satz. Und er beschreibt ganz gut eine spezielle Form des Spoofings – Visual Spoofing. Was in dem Beispiel harmlos erscheint, kann in der Praxis jedoch zum ernsthaften Problem werden. Spoofing im Allgemeinen bezeichnet die Angriffstechnik, bei dem man vorgibt jemand vertrauenswürdiges zu sein, der man gar nicht ist.
In diesem #FrontendFriday möchte ich euch von Zeichen erzählen, welche vorgeben ein anderer zu sein und wie man dies mit guter Validierung als Frontend-Entwickler/in am besten verhindert. In realen Projekten sollte die gleiche Validierung selbstverständlich auch im Backend (an der API) vorgenommen werden.
Das Thema Validierung ist eine zentrale Disziplin bei der Entwicklung von Frontends aller Art. Sie sorgt dafür, dass Daten valide erfasst werden. Der Schutz vor Visual Spoofing ist damit zentrale Aufgabe der Validierungslogik. Selbst wenn man komplett ohne Frameworks wie Angular oder Libraries wie React unterwegs ist, bietet der W3C-Standard einige Werkzeuge, um es mit einer guten Validierung aufzunehmen.
Validierung mit Boardmitteln des W3C Konsortium
Die scheinbar einfachste Form der Validierung ist, ob ein Feld ausgefüllt wurde oder nicht. Auch bekannt als Pflichtfeld (required).
Kopiere nun folgende Strings in das Eingabefeld und entdecke selbst, was die Standard-Browservalidierung damit macht. Hierzu jeweils in das deaktivierte, kleine Textfeld doppelklicken und anschließend mit [Strg]+[C] kopieren. Nach dem Einfügen via [Strg] + [V] auf den „Test“-Button klicken.
Wie du sicherlich bemerkt hast, wird sowohl das klassische Leerzeichen, als auch die anderen beiden, speziellen Zeichen nicht durch required „validiert“. Als Frontend-Entwickler/in wäre hier die naheliegendste Lösung, die JavaScript-Methode .trim() zu nutzen.
Dies funktioniert zwar bei allen normalen und ähnlichen Zeichen, die wie Leerzeichen erscheinen. Aber nicht bei sehr speziellen, wie z.B. dem 3. Mongolian Vowel Spearater. Wenn man beispielsweise dieses Zeichen alleine in die trim()-Funktion von JavaScript gibt, funktioniert es:
Das Popup-Fenster ist leer.
Wenn man jedoch dieses außergewöhnliche Zeichen mit normalen Zeichen kombiniert, geschieht Folgendes:
Es erscheint ein seltsames Zeichen nach „test“, obwohl das seltsame Zeichen eig. weg getrimmt werden sollte. Im Praxisfall könnte so eine triviale „trim()“-Validierung durch diesen Visual Spoofing Angriff also umgangen werden.
Dies ist nur eines von zahlreichen, angsteinflößenden Nebeneffekten im Umgang mit Zeichen, die dem Visual Spoofing zugeschrieben werden können.
Deshalb empfehle ich bei Anforderung einer strikten Validierung immer den Einsatz einer Whitelist-Validierung.
Was ist eine Whitelist-Validierung?
Kurz gesagt: bei der Whitelist-Validierung werden nur Zeichen akzeptiert, die als valide definiert sind.
Bei einer gegensätzlichen Blacklist-Validierung, werden alle Zeichen verhindert, die als nicht valide definiert sind. So auch bei der JavaScript trim()-Funktion, bei der spezielle Zeichen nicht verhindert werden.
Für Angular, React, als auch Vanilla-JS Projekte gibt es immer die Möglichkeit, via Pattern (Regex) eine entsprechende Whitelist-Validierung zu implementieren. Wie die genaue Regex aussehen muss, ist abhängig von den jeweiligen Anforderungen und den zu erfassenden Daten. Tipp: in der Praxis hat sich Chat-GPT in Kombination mit einem Regex-Checker eurer Wahl als sehr gute Hilfe zum Bau und/oder Prüfen von guten Regexes geeignet.
Noch etwas
Auch bei der Entwicklung unseres neuen Produktes Secure Password Share mussten wir uns auch mit dem Thema Visual Spoofing auseinandersetzen. Nicht aber bei der Daten-Validierung – welches Passwort gewählt wird, ist völlig frei gestellt – sondern zwischen UI und dem Benutzer.
Die Textarea zur Eingabe eines Passwortes oder Geheimnisses ist bewusst in der Serifen-Schrift „Consolas“ gehalten, um das zu Beginn des Blogpostes erwähnte Zitat „Ist das ein kleines L oder ein großes i?“ keine Chance zu geben:
Wäre hingegen „Arial“ gesetzt, würde die selbe Eingabe wie folgt aussehen:
Mehr Infos zu Secure Password Share
