Osservazione a margine: la lista Nexa sta diventando sempre più tecnica! Nel merito: On 13/09/2018 10:56, Stefano Quintarelli wrote:
cosa dovrebbe consentire javascript ? Sorprende (o meglio, ahimè, non sorprende più, fa solo rabbia) che si commettano sempre gli stessi errori: gli script nei file microsoft word, nei PDF, perfino Postscript nelle stampanti: <https://www.securityweek.com/printer-vulnerabilities-expose-organizations-at...>. Javascript nei browser non dovrebbe poter mandare richieste HTTP con contenuto arbitrario a destinazioni arbitrarie. Punto. Ci libereremmo di un bel po' di botnet.
puo' collegarsi a computer diversi da quello dell'utente ? certamente, per comunicare con il server da cui proviene.
può scaricare oggetti, diciamo immagini, da un computer con un determinato indirizzo ? beh, tutte le pagine web sono composte cosi'. (a partire dalla webmail)
una alternativa potrebbe essere che consenta di comunicare solo con il computer che lo ha servito. Speedtest, per esempio, non funzionerebbe. (forse nemmeno neubot, e nemmeno quasi tutto il mercato pubblictario).
Con l'attuale architettura non funzionerebbe quasi nulla: gli script raramente risiedono nel sito che li richiede e quindi quasi mai parlano col sito dal quale vengono. Se fossero autorizzati gli script solo del sito dal quale proviene la pagina principale escluderesti apis.google.com e miriadi di altri, sui quali risiedono quasi tutti gli script (e i font) usati in giro (favorendo ovviamente il tracking). Se però, come richiede molto ragionevolmente Giacomo, dovessimo espressamente autorizzare gli script che usano "liberamente" la rete, rischieremmo lo stesso effetto dei privacy cookies: dovresti farlo così spesso che alla fine autorizzeremmo senza guardare, aprendo la strada a attacchi più gravi di script che accedono a telecamera, microfono, dati, ecc... Oppure cambia l'architettura: il browser costruisce una macchina virtuale per ogni pagina e parla con un indirizzo alla volta, o al limite solo con quelli autorizzati in un campo dell'header HTTP ad hoc, o con quelli indicati da un meccanismo analogo a SPF per la mail. Ma se mi chiedi di scommettere, direi che la soluzione proposta sarà un sistema centralizzato di certificazione e firma degli script, stile app. Così "per la tua sicurezza" ti verrà chiesto di autorizzare solo gli script "non certificati sicuri" (come avviene per i certificati SSL) che non vengono da uno dei soliti repository. Sempre perché si commettono sempre gli stessi errori.
queste due cose che consente, possono essere usate da qualcuno per acquisire informazioni ? ogni cosa fatta su un computer da remoto consente di acquisire informazioni, dalla latenza di un collegamento al fatto che il computer a cui si collega risponda o meno. (che e' l'esempio sotto) Potresti anche inconsapevolmente contribuire a un repository "distribuito" di materiale che qualcun'altro non vuole tenere in casa: <https://github.com/seantmalone/HiveMind> Oppure un dispettoso potrebbe lasciarti del materiale di cui faresti fatica a giustificare il possesso in caso di sequestro.
e se uno non vuole consentirlo ? su firefox basta usare plugin come noscript e/o umatrix tra l'altro consiglio di farlo a tutti e collegarsi poi ad una pagina di youtube (ad esempio)
Mi associo caldamente alla raccomandazione. Umatrix è formidabile. Alberto
On 13/09/2018 10:29, Marco Ciurcina wrote:
"I'm not bad. I'm just drawn that way." (Jessica Rabbit in Who Censored Roger Rabbit?)
Per fortuna Firefox è software libero: c'è la speranza che qualche sviluppatore faccia un fork.
m.c.
In data giovedì 13 settembre 2018 00:13:03 CEST, Giacomo Tesio ha scritto:
Salve, e' stato pubblicato un nuovo exploit del bug che ho recentemente segnalato a Mozilla e Google.
Basically any old webpage can perform local network host discovery on you.
To implement this I made a webpage which attempts to load images from addresses 192.168.1.x. If you watch in the browser console it’ll show either net::ERR_CONNECTION_REFUSED for a host that’s up or net::ERR_ADDRESS_UNREACHABLE for a host that doesn’t exist. This is a CORS error which the javascript on the webpage is not allowed to differentiate by catching. But one error takes 3 ms to happen and the other takes 3 seconds! [...] A related thing a webpage in your browser might do is connect to localhost and control any unauthenticated local services. Taviso used this to great effect here https://github.com/spesmilo/electrum/issues/3374
https://rain-1.github.io/in-browser-localhostdiscovery
E con questo siamo a 2 exploit che vanificano firewall e proxy aziendali. E io ne ho descritti altri nel bug report!
E Mozilla tace. Io sono allibito.
Ricordate "this is the Web functioning as desinged"!
Giacomo
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa