Analizzare una URL

La scomposizione qui usa l’oggetto `URL` del browser, cioè l’implementazione dello standard WHATWG che decide davvero dove porta un indirizzo quando ci si clicca sopra. Non è un dettaglio di eleganza: è l’unico modo per essere certi che il risultato mostrato coincida con il comportamento reale.

Le espressioni regolari per le URL girano da vent’anni e sbagliano tutte nello stesso punto, i casi limite — ed è lì che si annidano gli inganni. Una URL costruita per sembrare di un dominio e puntare a un altro passa una regex e non passa un parser, quindi uno strumento basato su regex mostrerebbe esattamente quello che l’autore dell’inganno voleva far vedere.

La domanda che conta davvero è quasi sempre una sola: dove va a finire questo link. La risposta è l’host, e l’host è la parte fra lo schema e la prima barra — non quella che compare per prima nel testo, non quella che si legge meglio.

Da qui nascono gli inganni classici. `https://banca.esempio.it.tracker.example/` ha come host `tracker.example`, non `banca.esempio.it`; una `@` dentro l’indirizzo sposta tutto ciò che la precede nella parte delle credenziali e cambia l’host completamente. Vederlo estratto da solo, in un campo suo, è il motivo per cui questa pagina è utile su un link ricevuto per email.

La pagina non contatta il dominio, non risolve il nome, non segue redirect e non mostra anteprime. L’indirizzo viene scomposto come stringa e nient’altro, il che è esattamente ciò che serve quando quello che hai in mano è un link sospetto.

La conseguenza vale in entrambe le direzioni. Chi controlla quel dominio non viene a sapere che il link è stato esaminato, il che su un link di phishing con un identificatore unico dentro sarebbe un segnale prezioso per chi lo ha inviato. E l’indirizzo non viene consumato: un link a uso singolo, come una reimpostazione di password, resta valido dopo essere stato analizzato qui.

Un percorso che contiene `..` o `.` viene normalizzato: `/documenti/a/../b` diventa `/documenti/b`. Non è una semplificazione decisa da questo strumento, è quello che prescrive la specifica e quello che il browser fa prima di inviare la richiesta.

La conseguenza da conoscere è che il percorso mostrato è quello che il server riceverà davvero, e non quello che c’era scritto nel link. Se stai confrontando una URL con una riga di log, la forma normalizzata è quella giusta da confrontare — ed è anche il motivo per cui un tentativo di attraversamento di directory scritto in modo ingenuo si vede a colpo d’occhio qui.

Tutto quello che segue il `#` viene mostrato qui come parte della URL, e non compare in nessuna richiesta HTTP: il server non lo riceve. È la parte destinata al browser, usata per la posizione dentro la pagina e per lo stato di un’interfaccia.

Ne segue una cosa utile e una fuorviante. L’utile: se una URL presa da un log non ha frammento, non è stato tolto, non è mai arrivato. La fuorviante: il frammento è comunque nella cronologia, nei segnalibri e a disposizione di ogni script della pagina, quindi non è un posto sicuro — è solo un posto che non finisce nei log del server.

Se scrivi `https://esempio.it:443/`, la porta non viene mostrata. Non è una svista: 443 è la porta predefinita per `https`, come 80 lo è per `http`, e la specifica prescrive di ometterla perché l’indirizzo con e senza sono lo stesso indirizzo.

Conta in un caso pratico, il confronto fra origini. Due URL che differiscono solo per una porta predefinita esplicita hanno la stessa origine, quindi per le regole di CORS e per la memorizzazione dei dati nel browser sono indistinguibili. Una porta diversa dalla predefinita, invece, viene mostrata e crea un’origine diversa a tutti gli effetti.

Una URL che comincia con `htp://` non è un errore di sintassi: `htp` è uno schema perfettamente formato, semplicemente non ne esiste un gestore. Il parser lo accetta e lo mostra, perché il suo compito è dire com’è fatto l’indirizzo e non se qualcosa saprà cosa farne.

Vale anche per gli schemi che non hanno un host: `mailto:`, `tel:`, `data:` e `javascript:` sono URL a tutti gli effetti e non hanno niente dopo i due punti che assomigli a un dominio. Se il campo dell’host risulta vuoto, la prima cosa da guardare è lo schema — è quasi sempre lì che sta la spiegazione.

La sintassi `https://utente:[email protected]/` è prevista dalla specifica e i browser la trattano in modo ambivalente: alcuni la accettano, altri la rifiutano o avvisano, perché è stata usata per anni per far sembrare un indirizzo qualcosa che non era.

Qui utente e password vengono mostrati nei loro campi, per rendere visibile che ci sono. È un tipo di URL che compare ancora in vecchie stringhe di connessione e in script interni, ed è sempre un problema: quella password finisce nella cronologia, nei log dei proxy e in qualunque copia-incolla del comando. Se ne vedi una, la cosa da fare non è analizzarla ma sostituirla.

Un dominio con caratteri accentati non viaggia così com’è: viene convertito in Punycode, la forma che comincia con `xn--`, ed è quella che il sistema dei nomi risolve davvero. Un indirizzo come `perché.example` ha quindi due scritture, e la seconda è quella reale.

La forma Punycode viene mostrata apposta, perché è l’unica in cui due domini diversi si vedono diversi. Parecchi alfabeti contengono lettere identiche a quelle latine, e un dominio composto con quelle è indistinguibile a occhio dall’originale mentre in Punycode diventa una stringa `xn--` evidentemente estranea. È il modo pratico di riconoscere un attacco di omografia senza doverne sapere niente.