Analizzare una query string

Una query string può contenere lo stesso nome più volte, ed è una forma legittima: `?tag=a&tag=b` significa due valori per lo stesso parametro, ed è così che un modulo invia una selezione multipla. Qui compaiono come due righe.

Quasi tutti gli strumenti le perdono, perché trasformano la query in un dizionario e l’ultimo valore sovrascrive il primo. È il comportamento che nasconde le informazioni più interessanti proprio quando si sta indagando su qualcosa: due valori diversi per la stessa chiave sono spesso il segno di due sistemi che hanno scritto sulla stessa URL, ed è quello il dettaglio che stai cercando.

Non serve incollare un indirizzo intero: va bene la sola query string, con o senza il punto interrogativo iniziale. Se invece incolli una URL completa, la parte dopo il `?` viene estratta e il resto viene ignorato.

È una comodità che riguarda il caso reale. Quello che si copia da un log, da un export di statistiche o da una barra degli indirizzi arriva in tutte e tre le forme, e nessuna di queste è più giusta delle altre. Uno strumento che pretendesse una forma sola costringerebbe a ripulire il testo prima di poterlo leggere, che è l’operazione che si sta cercando di evitare.

Nelle query string si applica la regola di `application/x-www-form-urlencoded`, il formato con cui un modulo HTML invia i dati: lì lo spazio si scrive `+`. Siccome quello che si incolla qui è una query string per definizione, quella è la lettura corretta e viene applicata.

Il caso in cui dà fastidio è un valore che contiene un più vero — un numero di telefono in formato internazionale, una ricerca su `C++`. In una query string quel più andrebbe scritto `%2B`, e se non lo è si è già perso a monte: nemmeno il server dall’altra parte avrebbe modo di distinguerlo. La vista grezza mostra cosa c’era davvero nella stringa e permette di capire quale dei due casi sia.

Il parametro più interessante di una query string è spesso un altro indirizzo: una destinazione di redirect, una URL di callback, un `return_to`. Arriva codificato, quindi nella stringa originale si legge come una fila di `%3A%2F%2F` e non come un link.

Decodificato torna leggibile, e a quel punto si vede una cosa che prima non si vedeva: se quell’indirizzo annidato ha a sua volta dei parametri. Sono lo strato in cui si nascondono i difetti di redirect aperto e i token passati da un sistema all’altro, e per leggerli conviene ripartire dall’inizio, incollando qui la query dell’indirizzo interno.

La decodifica è attiva per impostazione predefinita perché il punto della pagina è poter leggere i valori. La vista grezza serve quando la domanda non è cosa dice il valore, ma com’era scritto nella stringa.

I casi sono tre e sono tutti diagnostici: capire se un valore era codificato due volte, cosa si riconosce dai `%25`; capire se uno spazio era un `+` o un `%20`, che dice quale sistema ha costruito la URL; e verificare cosa firmerebbe esattamente un meccanismo di firma, che lavora sulla forma codificata e non su quella leggibile. In tutti e tre i casi la forma grezza è il dato e quella decodificata è l’interpretazione.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_content` e `utm_term` sono etichette di campagna: dicono da dove arriva la visita, non chi la fa. Insieme a loro compaiono di solito gli identificatori di clic delle piattaforme pubblicitarie, che invece sono valori unici per singolo clic.

La differenza è quella che conta quando si guarda una URL condivisa. Le etichette di campagna si possono togliere senza perdere niente di funzionale, e gli identificatori di clic pure: sono la parte che collega quella visita a una persona precisa nel sistema di chi ha comprato l’annuncio. Riconoscerli riga per riga è il primo passo per decidere cosa di una URL vale la pena condividere.

Un token di accesso, una password, un codice fiscale, un numero di carta. Compaiono più spesso di quanto sia ragionevole, di solito perché mettere un valore in una query string è la cosa più rapida da fare e nessuno torna a rifarla.

Il problema è dove finiscono. Le URL complete stanno nei log del server e in quelli di ogni proxy in mezzo, nella cronologia del browser, nei segnalibri, negli export di statistiche e — se la pagina carica qualcosa da un altro dominio — nell’intestazione `Referer` inviata a un terzo. Sono almeno cinque posti che nessuno ripulisce, e per questo un valore riservato va in un’intestazione o nel corpo di una richiesta POST, mai in una query.

`?a=&b` contiene due parametri: `a` con un valore vuoto e `b` senza segno di uguale. Le due cose sono diverse nella stringa e vengono mostrate diverse, perché per parecchi server lo sono anche in lettura.

Il caso che si vede più spesso è un parametro presente come interruttore, tipo `?debug`, in cui conta l’esistenza e non il valore. Ma un valore vuoto capita anche per un difetto — un campo di modulo non compilato, una variabile non sostituita in un template — e distinguere «vuoto» da «assente» è quasi sempre l’informazione utile quando si sta cercando di capire perché una richiesta non fa quello che dovrebbe.

Una query string presa da un log è materiale sensibile per costruzione: contiene termini di ricerca, identificatori di sessione, riferimenti a ordini e, con imbarazzante frequenza, un indirizzo email in chiaro. Passarla a un servizio remoto per leggerla significherebbe comunicare tutto questo a un terzo.

Qui la scomposizione avviene nella scheda e non parte nessuna richiesta, quindi nel senso del GDPR non c’è nessun trasferimento da giustificare. Non viene nemmeno contattato il dominio che compare nella stringa, il che evita l’altro effetto indesiderato: segnalare a qualcuno che quella URL è stata esaminata.