Cache, navigazione privata e tracce che rimangono

Le lezioni 4.1 e 4.2 hanno esaminato i database della cronologia. Questa lezione tratta la cache del browser, che conserva copie di ciò che è stato effettivamente ricevuto, e la navigazione privata, che elimina la cronologia e la cache ma non le tracce conservate dal resto di Windows. Il compito dell'esaminatore è sapere quali tracce rimangono, dove trovarle e fino a che punto consentono di trarre conclusioni.

Che cosa contiene la cache e perché è importante

Un browser memorizza copie di pagine, immagini, script, fogli di stile e altri contenuti scaricati, in modo da poterli mostrare nuovamente senza recuperarli. Ogni voce della cache conserva la chiave (essenzialmente l'URL), il contenuto stesso e le intestazioni di risposta del server, quali Date (quando il server ha inviato la risposta), Last-Modified, Content-Type, Content-Length ed ETag, oltre agli orari scritti dal browser in base all'orologio locale. Ciò offre all'esaminatore tre elementi che il database della cronologia non fornisce: il contenuto visualizzato dall'utente, la prova che il contenuto è giunto a questo profilo del browser e un timestamp basato sull'orologio del server.

L'intestazione Date viene scritta dal server web, che normalmente è sincronizzato, ed è quindi un utile riferimento temporale esterno; una risposta servita da una CDN o dalla cache di un proxy conserva il proprio valore Date originale e un'intestazione Age ne indica quindi l'età. Confrontarlo con gli orari locali della stessa voce per misurare lo scostamento dell'orologio del dispositivo (lezione 3.5). Last-Modified fornisce un limite temporale inferiore: il contenuto non può essere stato ricevuto prima della sua ultima modifica sul server.

Cache di Chromium

Chrome conserva la propria cache HTTP in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Data; Edge utilizza la stessa struttura in %LOCALAPPDATA%\Microsoft\Edge\User Data\<profile>. Il formato su disco varia in base alla piattaforma e alla versione. Le versioni recenti di Chrome su Windows utilizzano il formato blockfile in Cache_Data:

Ogni voce contiene il flusso 0 (le informazioni della risposta HTTP analizzate, comprese le intestazioni) e il flusso 1 (il corpo, spesso ancora compresso con gzip o Brotli come al momento dell'invio). Chromium memorizza gli orari come microsecondi trascorsi dal 1601-01-01 UTC. Su Android, Linux, ChromeOS e macOS, Chromium utilizza invece per impostazione predefinita il formato simple cache: un file per voce denominato <16 hex digits>_0, con eventuali file _1 e _s e una cartella index-dir.

A partire da Chrome 86, la cache HTTP è partizionata per sito, quindi le chiavi possono iniziare con un prefisso come 1/0/_dk_ seguito dal sito di primo livello che ha caricato la risorsa. Tale prefisso indica per quale pagina è stata caricata un'immagine o uno script di terze parti.

Due cartelle adiacenti vengono spesso confuse con la cache. Code Cache (sottocartelle js e wasm) contiene JavaScript e WebAssembly compilati, indicizzati in base all'URL dello script: dimostra che gli script di un sito sono stati eseguiti, non ciò che è stato visualizzato. GPUCache contiene shader grafici compilati e ha scarso valore probatorio.

cache2 di Firefox

Firefox 32 e versioni successive utilizzano il formato cache2 nel profilo locale (non roaming): %LOCALAPPDATA%\Mozilla\Firefox\Profiles\<profile>\cache2\entries. Ogni voce è costituita da un file, denominato con l'hash SHA-1 di 40 cifre esadecimali della relativa chiave. Il file contiene prima il contenuto, poi i metadati: un hash di 4 byte dei metadati, gli hash dei blocchi (2 byte per ogni blocco da 256 KiB), un'intestazione (versione, conteggio dei recuperi, ultimo recupero, ultima modifica, frecency, ora di scadenza, dimensione della chiave, flag), la chiave che termina con l'URL (preceduto da brevi flag come a,:) ed elementi denominati come request-method e response-head, che contiene le intestazioni complete della risposta. Gli ultimi 4 byte sono un offset big-endian che punta all'inizio dei metadati ed equivale alla lunghezza del contenuto. Gli orari nell'intestazione sono espressi in secondi Unix a 32 bit, big-endian. cache2\index riepiloga tutte le voci (hash, frecency, flag) e non contiene URL.

Esempio svolto: lettura di una voce cache2

Un file di una voce ha una lunghezza di 15.240 byte. I suoi ultimi 4 byte sono 00 00 3A 98 = 0x3A98 = 15.000, quindi i byte da 0 a 14.999 costituiscono il contenuto memorizzato nella cache (iniziano con 89 50 4E 47, un PNG) e i metadati iniziano all'offset 15.000. Il campo dell'ultimo recupero contiene 69 B5 60 85 = 1.773.494.405 secondi dal 1970-01-01 = 2026-03-14T13:20:05Z. L'elemento response-head contiene Date: Sat, 14 Mar 2026 13:20:03 GMT. L'orologio locale e quello del server concordano entro 2 secondi, un valore compatibile con il normale tempo di trasferimento, quindi per questo periodo non è necessaria alcuna correzione dello scostamento.

Strumenti e limiti

Esempi gratuiti: ChromeCacheView e MozillaCacheView di NirSoft elencano URL, tipo di contenuto, ora del server e ora dell'ultima modifica ed esportano il contenuto; Plaso dispone dei parser chrome_cache e firefox_cache2; Hindsight analizza la cache di Chromium insieme alla cronologia. Qualunque sia lo strumento, aprire manualmente una voce e confermare gli orari.

Una cache ha dimensioni limitate. I browser ne determinano le dimensioni in base alle impostazioni o allo spazio libero su disco ed eliminano le voci usate meno di recente; le risposte contrassegnate con Cache-Control: no-store, comuni nelle pagine bancarie e di accesso, non vengono mai scritte; inoltre, l'utente può svuotare la cache. L'assenza di una voce nella cache non dimostra che una pagina non sia stata visitata.

Navigazione privata

La modalità di navigazione in incognito di Chrome, InPrivate di Edge e la navigazione anonima di Firefox funzionano tutte secondo lo stesso principio. Il browser non scrive la cronologia, l'elenco dei download, i dati dei moduli o le voci di ricerca; i cookie e i dati dei siti risiedono in memoria e vengono eliminati alla chiusura dell'ultima finestra privata; inoltre, la cache HTTP viene mantenuta in memoria anziché in Cache_Data o cache2. Tutti e tre conservano i file scaricati in una finestra privata e i segnalibri (preferiti) creati al suo interno, poiché questi vengono memorizzati al di fuori della sessione privata. La modalità privata protegge dal successivo utente del profilo, non dal sistema operativo, dalla rete o dai siti visitati.

Le tracce che rimangono si trovano quindi al di fuori dei database del browser:

Punti da applicare con precisione:

• Zone.Identifier. Per un download in una finestra normale, Chromium su Windows 10 e 11 scrive HostUrl e ReferrerUrl. Per un download in modalità in incognito non trasmette l'URL: il flusso conserva ZoneId=3, ma HostUrl contiene il segnaposto about:internet e ReferrerUrl è assente. Confermare il comportamento della versione presente nel caso in esame mediante un download di prova.
• Prefetch e BAM dimostrano che chrome.exe o firefox.exe è stato eseguito, non che sia stata utilizzata una finestra privata. Prefetch non registra gli argomenti della riga di comando, quindi un'opzione come --incognito compare solo dove vengono registrate le righe di comando, ad esempio nell'evento di sicurezza 4688 con il controllo della riga di comando abilitato; una finestra aperta con Ctrl+Shift+N in un browser già in esecuzione non viene affatto avviata con tale opzione.
• Cache del client DNS. Su un sistema attivo, ipconfig /displaydns elenca i nomi risolti dal client DNS di Windows; questa cache è volatile e scompare dopo un riavvio. Un browser che risolve autonomamente i nomi, come Chrome con il risolutore integrato abilitato, può aggirare questa cache, e un browser che utilizza DNS over HTTPS aggira anche i log del server DNS locale.
• I log di rete mostrano solitamente i nomi host, non gli URL completi: per HTTPS, un proxy che non intercetta il traffico registra l'host e la porta della richiesta CONNECT, non il percorso.

La cancellazione della cronologia non è navigazione privata

La cancellazione della cronologia elimina righe che sono state scritte; la navigazione privata non le scrive mai. La differenza è importante perché le righe eliminate possono sopravvivere. In SQLite generico, una riga eliminata finisce nello spazio libero all'interno di una pagina o in una pagina della freelist fino al riutilizzo o all'esecuzione di VACUUM, ma Chromium e Firefox compilano SQLite con la cancellazione sicura attivata, che sovrascrive con zeri il contenuto eliminato nel file principale. Possono tuttavia rimanere copie nel journal di rollback (History-journal in Chromium) o nel log write-ahead (places.sqlite-wal in Firefox), nelle copie shadow del volume e nei record di $UsnJrnl relativi ai file della cache eliminati al momento della cancellazione. SRUM e Prefetch non vengono affatto modificati dalla funzione di cancellazione del browser.

Formulare una conclusione a partire da tracce indirette

Quando esistono solo tracce indirette, indicare ogni fonte e i suoi limiti e non affermare come fatto l'uso di una finestra privata, a meno che qualcosa non lo dimostri. Una formulazione adeguata: "Le tracce sono compatibili con la navigazione su transfer.example.com in una finestra privata; la cronologia del browser non contiene alcuna registrazione di tale sito." Elencare quindi le alternative verificate: un altro browser o profilo, la cronologia cancellata o un dispositivo diverso.

Esempio svolto: una ricevuta senza cronologia

Una raccolta di triage su Windows 11 proveniente da un altro caso, per l'utente lferraz, mostra:

• History di Chrome: nessuna visita o download per transfer.example.com. La visita più antica nel database risale a 2026-04-21T15:02:41Z.
• C:\Users\lferraz\Downloads\upload-receipt.pdf, creazione $SI 2026-04-21T13:41:07Z, con Zone.Identifier ZoneId=3, ReferrerUrl=https://transfer.example.com/upload/done, HostUrl=https://transfer.example.com/r/8f3a/upload-receipt.pdf.
• Network Data Usage di SRUM per chrome.exe, utente lferraz, intervallo che termina alle 14:00:00Z (riga precedente 13:00:00Z): BytesSent 734.003.200, BytesRecvd 9.437.184.
• Cache_Data contiene solo index e nuovi file da data_0 a data_3 senza voci, creati il 2026-04-21T15:01:58Z.

Calcoli. 734.003.200 ÷ 1.048.576 = 700 MiB inviati e 9.437.184 ÷ 1.048.576 = 9 MiB ricevuti tra le 13:00:00Z e le 14:00:00Z, un rapporto di circa 78:1 compatibile con un caricamento. Il download delle 13:41:07Z rientra in tale intervallo.

Che cosa si può concludere. Un file è stato salvato alle 13:41:07Z da un URL su transfer.example.com, dopo una pagina di quel sito (/upload/done). chrome.exe, eseguito dall'utente lferraz, ha inviato circa 700 MiB nella stessa ora.

Che cosa deve spiegare l'ipotesi della navigazione privata. Il valore reale di HostUrl depone contro un download in modalità in incognito di Chrome, che avrebbe registrato about:internet. Una cache ricreata alle 15:01:58Z e una cronologia che inizia alle 15:02:41Z sono compatibili con una cancellazione dei dati di navigazione poco prima delle 15:02, non con la navigazione privata, che lascia intatta la cache normale. Passaggi successivi: eseguire il carving di History-journal, dello spazio non allocato e delle copie shadow per recuperare pagine precedenti di History, verificare in $UsnJrnl la presenza di file f_ eliminati intorno alle 15:01Z ed esaminare Edge e gli altri profili di Chrome, perché un altro browser basato su Chromium potrebbe aver scritto lo stesso flusso.

Che cosa non si può concludere. Né SRUM né Zone.Identifier indicano che cosa sia stato caricato o che i 700 MiB siano stati inviati a transfer.example.com; SRUM non contiene una destinazione. Per stabilire questo collegamento servono i log del proxy o del DNS della rete.

Focus sull'esame: Aspettarsi di dover leggere l'URL, l'intestazione Date o il tipo di contenuto di una voce della cache, oppure di calcolare l'offset dei metadati di Firefox cache2 a partire dagli ultimi 4 byte. Essere pronti a scegliere quali artefatti rimangono dopo la navigazione privata, a riportare un valore HostUrl o un conteggio di byte di SRUM e a riconoscere che un valore reale di HostUrl su un download di Chromium non è compatibile con la modalità in incognito. Le domande possono mettere a confronto la cronologia cancellata (copie potenzialmente recuperabili) con la navigazione privata (nessuna scrittura).

Punti chiave

• Le voci della cache contengono il contenuto, la chiave URL e le intestazioni di risposta del server; l'intestazione Date è un riferimento temporale esterno per verificare lo scostamento dell'orologio.
• Chrome su Windows utilizza Cache_Data in formato blockfile (index, da data_0 a data_3, file f_); Firefox 32+ utilizza un file in cache2\entries per ogni voce, con i metadati dopo il contenuto.
• Le cache hanno dimensioni limitate, non memorizzano le risposte no-store e possono essere svuotate, quindi l'assenza di una voce non dimostra nulla.
• La navigazione privata non scrive cronologia, cookie, dati dei moduli o cache su disco, ma rimangono download, segnalibri, Prefetch, BAM, SRUM, file LNK, memoria e log di rete.
• I download in modalità in incognito di Chrome riportano ZoneId=3 con HostUrl=about:internet; un URL reale indica un'altra origine.
• La cronologia cancellata viene sovrascritta con zeri nel database principale dalla cancellazione sicura, ma può sopravvivere nei journal, nei file WAL e nelle copie shadow; la navigazione privata non vi lascia nulla.