nccgroup/crosssitecontenthijackingProof-of-concept di content hijacking tramite Flash, PDF e Silverlight
Rilasciato sotto AGPL (vedi LICENSE per maggiori informazioni).
Questo progetto può essere utilizzato per fornire una prova di concetto per:
Nota: i file .XAP possono essere rinominati con qualsiasi altra estensione ma non possono più essere caricati cross-domain. Sembra che Silverlight determini l'estensione del file in base all'URL fornito e la ignori se non è .XAP. Questo può essere comunque sfruttato se un sito web consente agli utenti di usare ";" o "/" dopo il nome del file reale per aggiungere un'estensione ".XAP".
Nota: i file .XAP possono essere rinominati con qualsiasi altra estensione ma non possono più essere caricati cross-domain. Sembra che Silverlight determini l'estensione del file in base all'URL fornito e la ignori se non è .XAP. Questo può essere comunque sfruttato se un sito web consente agli utenti di usare ";" o "/" dopo il nome del file reale per aggiungere un'estensione ".XAP".
Nota: quando Silverlight richiede un file .XAP cross-domain, il content type deve essere: application/x-silverlight-app.
Nota: i file PDF possono essere utilizzati solo nel visualizzatore Adobe Reader (non funzioneranno con i visualizzatori PDF integrati di Chrome e Firefox)
Nota: leggere contenuti statici o dati pubblicamente accessibili non può essere considerato un problema. È importante rimuovere i risultati falsi positivi dai propri advisory. Si noti che l'uso del solo carattere asterisco ("*") nell'intestazione "Access-Control-Allow-Origin" non è un problema.
Esempio di utilizzo:
I tipi di file consentiti per l'upload dovrebbero essere limitati solo a quelli necessari per le funzionalità aziendali.
L'applicazione dovrebbe eseguire filtri e controlli sui contenuti di qualsiasi file caricato sul server. I file dovrebbero essere scansionati e validati accuratamente prima di essere resi disponibili ad altri utenti. In caso di dubbio, il file dovrebbe essere scartato.
Aggiungere le intestazioni "Content-Disposition: Attachment" e "X-Content-Type-Options: nosniff" alla risposta dei file statici proteggerà il sito web da attacchi di cross-site content-hijacking basati su Flash o PDF. Si raccomanda di applicare questa pratica a tutti i file che gli utenti devono scaricare in tutti i moduli che gestiscono il download di file. Sebbene questo metodo non protegga completamente il sito web da attacchi che utilizzano Silverlight o oggetti simili, può mitigare il rischio dell'uso di oggetti Adobe Flash e PDF, soprattutto quando il caricamento di file PDF è consentito.
I file di policy cross-domain Flash/PDF (crossdomain.xml) o Silverlight (clientaccesspolicy.xml) dovrebbero essere rimossi se non sono in uso e non esiste alcun requisito aziendale per applicazioni Flash o Silverlight che debbano comunicare con il sito web.
L'accesso cross-domain dovrebbe essere limitato a un insieme minimo di domini affidabili che necessitano di accesso. Una policy di accesso è considerata debole o insicura quando viene utilizzato un carattere jolly, specialmente nel valore dell'attributo "uri".
Qualsiasi file "crossdomain.xml" utilizzato per applicazioni Silverlight dovrebbe essere considerato debole poiché può accettare solo un carattere jolly ("*") nell'attributo domain.
La cache del browser dovrebbe essere disabilitata per i file corssdomain.xml e clientaccesspolicy.xml. Questo consente al sito web di aggiornare facilmente il file o limitare l'accesso ai servizi Web se necessario. Una volta verificato il file di policy di accesso client, rimane in effetto per la sessione del browser, quindi l'impatto della mancata memorizzazione nella cache per l'utente finale è minimo. Questo può essere segnalato come un problema di rischio basso o informativo in base al contenuto del sito web target e alla sicurezza e complessità dei file di policy.
Le intestazioni CORS dovrebbero essere revisionate per essere abilitate solo per dati statici o pubblicamente accessibili. In caso contrario, l'intestazione "Access-Control-Allow-Origin" dovrebbe contenere solo indirizzi autorizzati. Altre intestazioni CORS come "Access-Control-Allow-Credentials" dovrebbero essere usate solo quando necessario. Gli elementi all'interno delle intestazioni CORS come "Access-Control-Allow-Methods" o "Access-Control-Allow-Headers" dovrebbero essere revisionati e rimossi se non necessari.
Nota: l'uso dell'intestazione "Referer" non può essere una soluzione poiché è possibile impostare questa intestazione, ad esempio, inviando una richiesta POST usando Adobe Reader e PDF (vedi il file "xfa-manual-ContentHijacking.pdf" nella directory "objects"). Aggiornamento: l'impostazione dell'intestazione "referer" è stata gestita da Adobe, a meno che non si trovi anche un bypass ;)
Vedi la pagina del progetto per gli ultimi aggiornamenti/aiuto: https://github.com/nccgroup/CrossSiteContentHijacking
Soroush Dalili (IRSdl) di NCC Group
Anche il caricamento di un file JPG può portare al Cross Domain Data Hijacking (attacco lato client)! https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-can-lead-to-cross-domain-data-hijacking-client-side-attack/
Multiple PDF Vulnerabilities - Text and Pictures on Steroids http://insert-script.blogspot.co.at/2014/12/multiple-pdf-vulnerabilites-text-and.html
Comunicazione HTTP e sicurezza con Silverlight http://msdn.microsoft.com/en-gb/library/cc838250(v=vs.95).aspx
Spiegazione dei file Cross Domain e Client Access Policy per Silverlight http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight
Specifica dei file di policy cross-domain http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Impostazione di un file crossdomain.xml per lo streaming HTTP http://www.adobe.com/devnet/adobe-media-server/articles/cross-domain-xml-for-streaming.html
Sfruttamento di CVE-2011-2461 su google.com http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html
