In questo caso – come e’ gia’ successo piu’ volte per altre applicazioni – non vengono sfruttate falle di sicurezza del sistema operativo bensi’ eventi incondizionati che vengono interpretati in modo arbitrario dal software applicativo.
In pratica, se decido di utilizzare un tool che mi permette di archiviare i miei dati utilizzando un sofisticato algoritmo di crittazione, supposto che l’algoritmo sia indecifrabile, dovro’ comunque preoccuparmi che il sistema di autenticazione possa essere compromesso o superato attraverso tecniche di reverse engineering o da uno script ad hoc dato in pasto all’applicazione.
Questa problematica non e’ nuova e scenari di questo tipo sono piuttosto frequenti. Proviamo ora a restringere l’insieme e affrontiamo l’argomento per un sottoinsieme minore: passiamo da una applicazione che gira all’interno di un sistema operativo ad una applicazione che lavora esclusivamente all’interno di un browser client.
E’ il caso delle estensioni e plugin per i browser di ultima generazione, solitamente semplici o complessi script che ci aiutano a semplificare i nostri lavori e a rendere piu’ piacevole la navigazione.
Alcune estensioni (faccio riferimento a Firefox) dispongono di alta priorita’ di interpretazione per il contenuto delle pagine web, pensate ad una delle tante estensioni per il parsing e la manipolazione degli headers o del DOM. Nonostante siamo comunemente abituati ad assistere a nuovi PoC per i browser client facciamo – comunque – affidamento alla robustezza del nostro browser (FF, IE7, Opera, etc.) senza preoccuparci minimamente delle piccole applicazioni che installiamo e facciamo lavorare all’interno. Dunque, sono sempre piu’ convinto che vista la natura delle estensioni e delle loro azioni/prestazioni non e’ da escludere che in futuro vengano realizzati PoC in grado di attaccare i browser per via indiretta.
Technorati tags: PoC Applicazioni, Poc Estensioni
Se posso aggiungerei che anche all’interno delle stesse estensioni che scarichiamo e installiamo può esserci codice fallato, insicuro o malizioso. Direi anche di fare attenzione a tutte quelle estensioni che permettono di fare il login attraverso di esse. Spesso questo avviene postando le credenziali di accesso “in chiaro”, naturalmente basta che qualcuno sniffi i dati che passano attraverso la vostra rete per avere accesso a queste informazioni. Una “famosa” estensione di firefox per twitter per esempio ne è una dimostrazione…
Concordo con aloha : aggiungo che il più delle volte il “danno” deriva dall’impossibilità di marcare in maniera netta dominio locale e dominio remoto : le estensioni dovrebbero lavorare sul dominio locale e per spedire dati nel dominio remoto dovrebbero usare delle interfacce protette verso tale dominio. Codice che gira in locale non dovrebbe poter ricevere direttamente input che provengono da remoto ; viceversa codice che gira in dominio remoto (javascript) non dovrebbe poter accedere alle risorse locali. In teoria dovrebbe essere così : in pratica poi succede che vengono definiti Internet OS delle soluzioni come eyeOS
Complimenti, ottime riflessioni
Concordo con l’anonimo del 2 commento ; in ff/mozilla javascript è sicuramente il “mezzo naturale” attraverso cui far passare exploits per le estensioni per un motivo molto semplice : non è possibile impostare la sameOrigin policy. Per chiarirci in ff/mozilla esistono 3 policy di sicurezza : allAccess ( accesso illimitato ), noAccess ( accesso negato ) e sameOrigin ( accesso vincolato alla medesima provenienza : stesso dominio, stesso sito , etc … ) l’accesso a gli elementi del DOM è limitato alla sameOrigin policy, mentre per javascript è possibile impostare noAccess oppure allAccess. Certo è possibile creare una policy personalizzata attarverso cui dare accesso illimitato ai siti/location in whitelist e negare ogni accesso al resto ( come fa l’estensione di ff NoScript ) ma la sameOrigin resta IMHO la soluzione più sicura anche se mi rendo conto che applicata a javascript renderebbe tutto molto complicato.