Uno dei consigli più diffusi durante la formazione anti-phishing è quello di spostare i messaggi sospetti nella cartella Posta indesiderata di Outlook per verificare dove puntano davvero i link. Il client di posta di Microsoft, in quella sezione, rimuove buona parte della formattazione HTML e mostra in chiaro le destinazioni reali dei collegamenti. Un meccanismo utile, nessun dubbio. Ma non sempre funziona come ci si aspetterebbe.
Il punto è che molte campagne di phishing giocano proprio sulla discrepanza tra il testo visibile di un pulsante e la destinazione reale del link nascosto dietro. Outlook, mostrando direttamente l’URL di destinazione nella Posta indesiderata, dovrebbe ridurre il rischio di clic accidentali. Eppure un comportamento anomalo osservato di recente da Jan Kopriva (ISC) ha messo in luce un problema concreto: il sistema di anteprima dei link nella cartella Posta indesiderata può essere aggirato. E la cosa curiosa è che il motivo non ha nulla a che fare con tecniche sofisticate o codice malevolo particolarmente ingegnoso.
Quando Outlook non mostra quello che dovrebbe mostrare
Il caso analizzato riguarda un’email di phishing con il classico pulsante dal tono urgente, quelli che invitano a visitare un sito e inserire dati personali. Una volta aperta nella cartella Posta indesiderata, Outlook non mostrava alcun URL associato al pulsante. Il testo appariva come un semplice elemento statico, privo di qualsiasi destinazione. Tutto tranquillo, insomma. Peccato che lo stesso messaggio, nella casella Posta in arrivo, contenesse un collegamento perfettamente funzionante e cliccabile.
Il motivo si è rivelato più banale del previsto. Analizzando il codice sorgente dell’email (tramite la funzione “Visualizza origine messaggio”), è emersa un’anomalia nell’attributo HREF del tag anchor HTML. Il collegamento non utilizzava un URL completo con il classico https:// iniziale, ma solo l’indicazione diretta del nome di dominio e del percorso. Secondo la specifica IETF RFC 3986, un indirizzo valido dovrebbe includere almeno schema, authority e path quando si tratta di riferimenti assoluti.
Outlook, nella visualizzazione della Posta indesiderata, sembra utilizzare una routine di parsing più rigida che ignora gli attributi HREF incompleti o relativi. Il motore di rendering normale, quello usato per la Posta in arrivo e le altre sezioni, continua invece a trattarli come collegamenti cliccabili. Due componenti interni dello stesso software che non adottano lo stesso criterio di validazione. Un link senza schema iniziale non rappresenta formalmente un URL completo, certo. Ma la conseguenza pratica è problematica: qualcuno potrebbe interpretare l’assenza di collegamenti visibili come un segnale di sicurezza, mentre il pulsante rimane comunque attivo quando l’email viene aperta normalmente.
Perché le email HTML restano un terreno così imprevedibile
Le email HTML rappresentano uno degli elementi più frammentati in assoluto in termini di gestione tra i vari client di posta. Outlook desktop utilizza ancora componenti derivati dal motore di rendering di Word, mentre Outlook Web App e il nuovo Outlook basato su WebView2 seguono logiche completamente differenti. Lo stesso messaggio può apparire in modi diversi a seconda della piattaforma su cui viene aperto.
Questa frammentazione produce effetti collaterali continui. Alcuni client correggono automaticamente HTML malformato, altri tentano di normalizzare gli attributi, altri ancora bloccano selettivamente script, CSS o riferimenti esterni. Il risultato è che tecniche apparentemente banali possono modificare il comportamento di sicurezza del software senza che nessuno se ne accorga.
Nel caso specifico, il phishing sfrutta un dettaglio marginale del parsing HTML. Non una vulnerabilità remota nel senso classico del termine. Questo tipo di comportamento riduce però l’affidabilità di uno strumento che molti professionisti consigliano durante la formazione anti-phishing. Outlook comunica implicitamente all’utente che non ci sono link da controllare. E invece il link esiste eccome.
