Blog-Logo auf schwarzem Grund mit dem Schriftzug "Discover What's Next in Tech!"

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.


  1. Klassisches Leerzeichen (U+002)
  2. Geviert Abstand (U+2001)
  3. Mongolian Vowel Separater (U+180e)

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:

SPS

Wäre hingegen „Arial“ gesetzt, würde die selbe Eingabe wie folgt aussehen:

SPS

 

Mehr Infos zu Secure Password Share

 

Markus Wingler

Über MICH

Markus Wingler ist Senior Software Developer, Fachteamleiter für „Fullstack JavaScript Applications“ und arbeitet seit 2010 bei doubleSlash. Nachdem er seine Ausbildung als Anwendungsentwickler erfolgreich abgeschlossen hat, studierte er Angewandte Informatik (B. Sc.) an der DHBW Stuttgart. Durch seine jahrelange Erfahrung ist er zum Experte in der Entwicklung und Konzeption von modernen Webanwendungen im B2B-Umfeld geworden. Auch das Themenfeld der mobilen Apps gehören zu seinen Schwerpunkten. Vor allem neue Technologien und Trends im Mobile- und Web-Bereich begeistern ihn.

Alle Beiträge von Markus Wingler

Mehr erfahren

Weitere Infos auf unserer Website und in unserem Newsletter

Pfeil hoch