Decodificare Base64

Guarda cosa finisce davvero in un decodificatore Base64: un JWT, per vedere di chi è il token. Un valore preso da un secret di Kubernetes, che è una password scritta in modo da non sembrarlo. Un’intestazione di Basic Auth estratta da un log di richieste. Il payload di un webhook di produzione.

Tre di quei quattro sono credenziali e il quarto sono di solito dati di clienti. Un decodificatore che gira su un server li ha visti tutti e li ha nei propri log, indipendentemente da cosa avesse in mente chi li ha incollati. Qui il conto si fa nella tua scheda, e il pannello di rete è come lo verifichi invece di una promessa da accettare.

Un JSON Web Token sono tre segmenti in Base64 sicuro per URL separati da punti. Incolla quello centrale e ottieni il payload: le claim, il subject, la scadenza come timestamp Unix. Incolla il primo e ottieni l’header, che dichiara l’algoritmo di firma. Entrambi sono leggibili da chiunque abbia il token, il che sorprende molti e non dovrebbe: un JWT è firmato, non cifrato.

Il terzo segmento è la firma sui primi due, e verificarla richiede la chiave. Quindi qui vedrai che un token dichiara di scadere martedì prossimo; non vedrai se qualcuno ha modificato quella dichiarazione. Se sul contenuto ci fai affidamento, la firma va verificata dove la chiave c’è — cioè non in un browser altrui.

Il Base64 trasporta byte, e i byte non sono sempre caratteri. Decodifica l’inizio di un PNG e quello che esce è una firma di formato, la lunghezza di un chunk e materiale binario: nella migliore delle ipotesi una fila di caratteri di sostituzione. Quasi tutti i decodificatori te la consegnano lo stesso, lasciandoti a fissare un risultato senza sapere se l’input era sbagliato o se semplicemente non era testo.

Questa pagina lo dice invece di fingere. Il decodificatore è severo sull’UTF-8, quindi i byte che non formano testo valido vengono segnalati come tali, con il loro numero, invece di essere sostituiti in silenzio. «Base64 valido di un file» e «non è Base64» sono due problemi diversi e ricevono due risposte diverse.

Qui il padding è facoltativo. Un segmento di JWT non ne ha, perché `=` è un carattere riservato in una URL, e un decodificatore che lo pretende rifiuta ogni token reale che gli venga passato — una specifica applicata contro l’intera popolazione delle cose che descrive.

Prima di decodificare, i segni di uguale mancanti vengono ricostruiti dalla lunghezza, che è sempre ricavabile: un resto di due caratteri vuole due uguali, un resto di tre ne vuole uno, e un resto di uno è invece un segnale che la stringa è troncata. Quel caso viene detto, perché è l’unico in cui l’aggiustamento sarebbe un’invenzione.

Il Base64 standard finisce con `+` e `/`; la variante sicura per URL usa `-` e `_`. Non si possono confondere fra loro, quindi qui vengono tradotti entrambi e non c’è nessuna impostazione da sbagliare.

La conseguenza pratica è che una stringa mista — cosa che capita quando qualcuno ha sostituito i caratteri a mano su metà valore, o quando due sistemi hanno codificato pezzi diversi dello stesso payload — si decodifica lo stesso. Non è un formato legittimo, ma rifiutarla non aiuterebbe nessuno: chi ha quel valore in mano vuole leggerlo, non riceverne la pagella.

Spazi, tabulazioni e a capo vengono tolti prima di qualsiasi altra cosa. Il motivo è un blocco PEM: un certificato o una chiave privata arrivano spezzati a 64 caratteri, e nessuno li ricongiunge a mano. Lo stesso vale per il Base64 di MIME, spezzato a 76.

Restano da togliere solo le cose che non sono spazi: le righe `-----BEGIN CERTIFICATE-----`, che sono delimitatori e non contenuto, e il prefisso `data:image/png;base64,` di una data URI, che è metadato. Sono anche la causa più comune del messaggio «non è Base64», perché a occhio sembrano parte del valore.

Il fatto che qualcosa si decodifichi non dice niente su cosa sia. Un JWT scaduto si decodifica benissimo, un token con la firma manomessa anche, e una stringa che era solo un identificatore casuale produrrà byte senza significato senza che nulla protesti.

La distinzione conta perché il passo successivo è quasi sempre una decisione: fidarsi di una claim, accettare una richiesta, credere a un valore di configurazione. Questa pagina risponde a «cosa c’è scritto», mai a «è vero». Le due domande vanno tenute separate anche quando la prima è appena stata soddisfatta in modo convincente.

Il rombo con il punto interrogativo, U+FFFD, non è mai nei dati: è quello che un decodificatore mette al posto di byte che non riesce a interpretare. Vederlo significa che da qualche parte, a monte, un pezzo di testo è stato letto con la codifica sbagliata — non che il testo contenesse quel carattere.

Il caso italiano tipico è una stringa che era UTF-8 ed è stata letta come Latin-1: la `à`, che in UTF-8 è `c3 a0`, diventa due caratteri, `Ã` e uno spazio unificatore. Se nel risultato compaiono `Ã`, `è` o `ì`, il Base64 era corretto e il guasto è precedente, in chi ha scritto la stringa.

In un manifesto Kubernetes i valori di un `Secret` sono in Base64, e questo trae in inganno con regolarità: sembrano protetti e non lo sono. Il Base64 lì serve a far passare byte arbitrari dentro un file YAML, e nient’altro. Chi legge il manifesto ha la password.

Da qui discende la parte pratica: un manifesto con dentro dei secret non va in un repository, non va in un ticket e non va in una chat. E il valore che incolli qui è una password vera, motivo per cui la pagina che lo decodifica non deve essere un servizio remoto — la differenza fra i due comportamenti è tutta in dove avviene il conto.

Il payload di un webhook contiene spesso indirizzi email, nomi e identificatori di ordine. Se quel payload viene decodificato sul tuo dispositivo non c’è nessuna comunicazione di dati personali verso di noi, e quindi non serve nessun accordo che la regoli: la cosa più semplice da difendere davanti a un controllo è un dato che non si è mai mosso.

Quello che resta è tutto scritto nell’informativa e riguarda la visita, non il campo: la richiesta della pagina, la pubblicità, e le statistiche se dai il consenso. Confondere i due piani è comodo per chi vende uno strumento online; distinguerli è l’unica versione che regga a una domanda precisa.

Chi decodifica ha in mano qualcosa che non capisce e cinque domande su cosa possa essere andato storto. Chi codifica sta costruendo qualcosa e ne ha una sola. Un’unica pagina con un selettore dedicherebbe metà del suo testo alla domanda sbagliata per chiunque la apra.

Così i due versi hanno due pagine, e quella per codificare è a un clic da qui. Lì si parla di alfabeti, di padding da produrre e del costo di un terzo in più; qui si parla di token, di byte che non sono testo e di come si riconosce un copia-incolla incompleto.