Ho rivisto le due possibili configurazioni indicate nel precedente messaggio e confermo che dovrebbero essere ultimate. Se la 1° funziona senza interferire con il mod_pagespeed converrebbe provare ad adottarla.
Sono stato abbastanza dubbioso se introdurre la contromisura o meno: lanciare un attacco BREACH non è per nulla banale (bisogna preparare un sito-trappola e convincere la vittima a visitarlo) e non è sfruttabile via Internet, ma solo da qualcuno nella stessa LAN o Wi-Fi della vittima che sia in grado di catturare il traffico HTTPS in transito.
Ciò premesso, ho comunque deciso di introdurre la contromisura. L'effetto collaterale è che da domani pomeriggio (05/01/2015) in avanti, il nostro server disattiva la compressione HTTP della pagina se il browser dell'utente non indica che la l'URL dal quale proviene è interna a TurboLab.it (HTTP referer).
Questo si verifica quando il visitatore apre TurboLab.it:
partendo dal Preferito che si era salvato nel browser
seguendo un link su un altro sito che non sia in questo elenco: google.com, google.it, mail.google.com, facebook.com, m.facebook.com, feedly.com, bing.com
scrivendo direttamente il nostro URL nella barra degli indirizzi del browser
utilizzando un PC sul quale è installata una suite di sicurezza che blocca HTTP referer a prescindere (spero non ne esistano più in circolazione, ma non ne sono sicuro)
La misura è attiva su TurboLab.it ma non su cdn.phporn.net, dato che lì non viene gestito input-utente e quindi è immune a priori.
@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
Zane ha scritto:Ciò premesso, ho comunque deciso di introdurre la contromisura. L'effetto collaterale è che da domani pomeriggio (05/01/2015) in avanti, il nostro server disattiva la compressione HTTP della pagina se il browser dell'utente non indica che la l'URL dal quale proviene è interna a TurboLab.it (HTTP referer).
La prima delle due possibili mitigazioni che ho proposto precedentemente opera proprio sulla compressione HTTP in base al referer; la seconda invece, sempre in base al referer, evita di trasmettere i cookie (che possono consentire l'accesso ad una sessione autenticata).
Nel primo caso, dopo aver visitato almeno un link all'interno di TurboLab.it (compreso bug), la situazione ritorna normale (compressione abilitata). Questa mitigazione non impatta realmente l'utente ma piuttosto il carico del server (in termini di banda utilizzata). In realtà il carico non dovrebbe incrementare in maniera sensibile.
Nel secondo caso, l'utente con referer esterno a TLI, anche se precedentemente autenticato, risulterà come visitatore rispetto alla prima visita, dopo aver visitato almeno un link all'interno di TurboLab.it (compreso bug), la situazione dovrebbe tornare normale (trasmissione dei cookie abilitata). Questa misura provoca un piccolo disagio all'utente ma, in termini di prestazioni e complessità è forse la migliore.
Zane ha scritto:@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
OK. Speriamo che questa modifica non si scontri con il mod_pagespeed vanificandone l'efficacia.
Ora che ci penso phpBB permette di autenticarsi e gestire sessioni anche in assenza dei cookie (utilizza dei parametri nell'url) quindi è possibile che l'unica soluzione che garantisca un livello di sicurezza consistente è rappresentato dalla prima mitigazione.
La soluzione scarta-cookie non è applicabile: considerate le circostanze necessarie per sfruttare la vulnerabilità, reputo che non valga la pena sacrificare l'auto-login e tante altre cosine che dipendono dai cookie per gestirlo. Inoltre, se ricordo correttamente (sono effettivamente alcuni anni che non ci guardo), l'accesso senza cookie a phpBB usa un session-ID via querystring che non fa altro che sostituire un punto d'attacco con un altro... ma, soprattutto, è una schifezza che non voglio nell'URL.
La soluzione disattiva-compressione è completamente efficace e la penalizzazione ragionevole: questo il motivo per cui ho preferito quella.
Zane ha scritto:Inoltre, se ricordo correttamente (sono effettivamente alcuni anni che non ci guardo), l'accesso senza cookie a phpBB usa un session-ID via querystring che non fa altro che sostituire un punto d'attacco con un altro... ma, soprattutto, è una schifezza che non voglio nell'URL.
Ho espresso una simile perplessità nel mio precedente messaggio.
Zane ha scritto:La soluzione disattiva-compressione è completamente efficace e la penalizzazione ragionevole: questo il motivo per cui ho preferito quella.
Zane ha scritto:@hashcat: da mezzogiorno di domani, puoi gentilmente fare una verifica di quanto ho detto e confermarmi che tutto stia funzionando correttamente?
Ho appena verificato e sembra funzionare ma... sbaglio o hai inserito nella whitelist anche alcuni host esterni a TLI (ad esempio Google, Bing): è il comportamento desiderato (o si tratta di un bug) ?
Inserendo un messaggio, dichiari di aver letto e accettato il regolamento di partecipazione.
Nello specifico, sei consapevole che ti stai assumendo personalmente la totale responsabilità delle tue affermazioni, anche in sede civile e/o penale,
manlevando i gestori di questo sito da ogni coinvolgimento e/o pretesa di rivalsa.
Dichiari inoltre di essere consapevole che il messaggio sarà visibile pubblicamente, accetti di diffonderlo con licenza
CC BY-NC-SA 3.0 (con attribuzione a "TurboLab.it") e rinunci ad ogni forma di compensazione (economica o altro).
Rinunci inoltre esplicitamente a qualsiasi pretesa di cancellazione del messaggio.
Re: Applicare contromisure per attacco BREACH su TurboLab.it
