Base64-Decoder

Eine in der Praxis angetroffene Base64-Zeichenkette könnte Standard-Base64 sein — von einem E-Mail-Anhang, einer Daten-URI, einer Konfigurationsdatei — oder Base64URL, am häufigsten von einem der drei durch Punkte getrennten Segmente eines JWT. Da sich die beiden Varianten nur in drei Zeichen unterscheiden, zwingt ein Decoder, der auf genau einer Form besteht, Sie, manuell `-` gegen `+` und `_` gegen `/` zu tauschen, bevor er ein Token-Segment akzeptiert, ein unbequemer zusätzlicher Schritt für etwas, das ein einfaches Einfügen sein sollte. Beide Varianten zu akzeptieren bedeutet, dass ein JWT-Payload-Segment direkt eingefügt werden kann, ohne vorher zu wissen oder sich darum zu kümmern, welche Base64-Variante es zufällig ist.

Nicht alles in Base64 Kodierte ist überhaupt Text — Bilder, Verschlüsselungsschlüssel und andere Binärdaten werden aus denselben Gründen der Textsicherheit ebenfalls häufig in Base64 kodiert. Eines davon zu dekodieren erzeugt rohe Bytes, die als verzerrte, unlesbare Zeichen erscheinen, wenn sie als Text interpretiert werden, was zu erwarten ist statt ein Zeichen dafür, dass das Dekodieren gescheitert ist: Die Operation hat die Kodierung korrekt umgekehrt, aber die zugrunde liegenden Bytes waren nie dafür gedacht, als UTF-8-Text gelesen zu werden.

Eine unbekannte, Base64-artig aussehende Zeichenkette hier einzufügen und zu prüfen, ob sie zu etwas Lesbarem dekodiert, ist ein schneller erster Schritt, um zu untersuchen, was ein Datenwert wirklich ist — ein Konfigurationswert, ein Cookie, ein an unerwarteter Stelle gefundenes Token-Fragment. Eine Zeichenkette, die sauber zu lesbarem JSON oder Klartext dekodiert, bestätigt, dass es sich wirklich um Base64-kodierte Daten handelt; eine, die beim Dekodieren Kauderwelsch erzeugt, ist entweder überhaupt kein Base64, oder Binärdaten in Base64 kodiert statt Text, und beide Fälle grenzen ein, was als Nächstes zu untersuchen ist.