Le sandbox sono sopravvalutate?

4

Mi sono imbattuto in quanto segue nel blog dello sviluppatore NoScript Giorgio Maone .

Innanzitutto cita il seguente articolo di ArsTechnica su bug XSS in Adobe Flash :

As useful as sandboxes are in restricting potentially buggy code to a small part of the operating system, they do nothing to minimize the damage that can be done by attacks that exploit universal XSS flaws, researchers said.

Quindi sottolinea la seguente affermazione interessante:

I was already preaching this four years ago: the more our assets move “in the cloud”, the less traditional security measures, meant to protecting just your local system, suffice.

The battlefield is the web now, and there’s no coming back…

Domanda

È vero? La sicurezza del browser dovrebbe concentrarsi maggiormente sugli exploit che si svolgono "solo nel web"?

Con "nel web" intendo exploit che non tentano di installare malware sul computer dell'utente, ma tentare di rubare dati o abusare tramite XSS o clickjacking, ad esempio.

È un dato di fatto che faccio così tanto sul web adesso. Il mio account di posta elettronica è cresciuto fino all'importanza del portafoglio digitale . La maggior parte dei miei account internet e altre informazioni sensibili vengono trasmesse via Internet.

Il PR di Chrome pubblicizza con successo Chrome come browser molto sicuro. Che è probabilmente vero quando si parla di proteggere il computer da malware. Ma proteggere la mia attività online è altrettanto importante.

    
posta 20.06.2012 - 17:46
fonte

2 risposte

4

No. Le sabbiere non sono sopravvalutate. Sono molto utili. Non sono un proiettile d'argento - non risolvono tutti i problemi di sicurezza - ma hanno un valore sostanziale.

Davvero, non penso che questo sia particolarmente nuovo. Se leggi il documento originale che descrive l'architettura di sicurezza di Chrome, spiega chiaramente perché il sandboxing è prezioso, pur chiarendo i suoi limiti. Ad esempio, l'introduzione dice:

Chromium's architecture is designed to mitigate the most severe vulnerabilities, namely those vulnerabilities that let an attacker execute arbitrary code. [...] We find that 38 of the 87 rendering engine vulnerabilities allowed an attacker to execute arbitrary code and would have been mitigated by Chromium's architecture. These account for 70.4% (38 of 54) of all disclosed vulnerabilities that allow arbitrary code execution.

Pertanto, l'architettura di Chrome offre un enorme contributo per mitigare le vulnerabilità più gravi che si possono avere in un browser.

Allo stesso tempo, il team di Chrome non ha mai affermato che il sandboxing è un proiettile d'argento. Ad esempio, vedi "Out of Scope Goals" in quel documento per una descrizione chiara di alcune vulnerabilità che l'architettura sandboxing di Chrome non tenta di mitigare. Chiunque abbia seguito questo dovrebbe già essere consapevole del fatto che la sandboxing non pretende di arrestare tutti i problemi di sicurezza.

Leggi il foglio qui:

Ricordare che le vulnerabilità che consentono a un utente malintenzionato di eseguire codice dannoso sul sistema locale (noto anche come download drive-by) rappresentano il tipo più grave di vulnerabilità. Un utente malintenzionato che sfrutta tale vulnerabilità può anche attaccare tutti i dati "nel cloud" o sui server. Il contrario non è vero. Di conseguenza, i download drive-by sono il tipo più grave di vulnerabilità di avere in un browser web.

Se guardi qualche anno fa, queste vulnerabilità "drive-by-download" nei browser erano molto comuni. Data la loro gravità e prevalenza, è naturale che ricercatori e professionisti della sicurezza abbiano speso molte energie alla ricerca di modi per mitigare o eliminare questo tipo di vulnerabilità. La comunità della sicurezza ha trovato modi ragionevoli per ridurre significativamente la prevalenza di tali vulnerabilità.

Quindi, certo, una volta che si sono compiuti buoni progressi nell'eliminare le più comuni e gravi vulnerabilità, è naturale iniziare subito a considerare come affrontare i problemi successivi più seri. Ma ciò non significa che il sandboxing sia "sopravvalutato". E, ciò non significa che l'energia messa in gioco dai download drive-by sia stata sprecata o malriposta. Non lo era. Era importante e oggi è importante.

    
risposta data 03.08.2012 - 06:22
fonte
0

Questa è una domanda interessante. Stiamo parlando di attaccare il browser contro l'attacco dell'applicazione e cosa succede all'interno dell'applicazione.

Entrambi continueranno ad essere importanti. La vera differenza dal punto di vista dell'utente finale è che puoi scegliere quale browser utilizzare, quali applicazioni / fornitori web esplorare - hai il controllo. Dal lato dell'app web, questo è davvero il problema dello sviluppatore.

Nella lettura del post sul blog originale, non mi sembra che stia insinuando che il browser debba avere un qualche tipo di debug in tempo reale per rilevare XSS e CSRF. Penso che stia solo facendo notare che la maggior parte degli sviluppatori non si preoccupa della sicurezza. Mentre è possibile utilizzare XSS e CSRF per attaccare un attacco Flash esistente, ciò che mi viene in mente dalla sua citazione è qualcuno che mette su un sito di malware e ti fa andare lì - sandboxing potrebbe aiutare qualche codice dannoso a fuggire al sistema operativo . Mentre un attacco XSS è in genere contro un sito e un'applicazione legittimi che l'utente malintenzionato non controlla direttamente.

Un'altra possibilità è che l'autore abbia visto di recente alcune società AV parlare di come la loro sandbox ti proteggerà dalle minacce di Internet (l'ho visto come una funzionalità in alcuni recenti suite AV, un browser sandbox per siti non fidati) ed era arrabbiato riguardo al focus ancora sull'utente finale. Dal punto di vista dell'utente finale, puoi solo impedire a XSS di colpirti in un numero limitato di casi, ad esempio ottenere un collegamento che ovviamente ha uno script impostato in un parametro GET e scegliere di non fare clic su di esso o disabilitare JavaScript e cookie, ecc. ; CSRF potrebbe ancora essere in gioco.

    
risposta data 24.06.2012 - 08:20
fonte

Leggi altre domande sui tag