Non sono sicuro di avere capito la domanda. Non hanno fatto cosa? Correggere il bug che hai notificato nei loro browser?
Perché dal loro punto di vista non é un bug… E’ una caratteristica insita nel software. Infatti quella che tu chiami mitigazione, corrisponde in realtá a tornare a Internet 1.0, che dal loro punto di vista é inaccettabile.
Inoltre esistono giá dei plugin che permettono di bloccare i javascript remoti, e di default i browser sono impostati per bloccare javascript maligni.
Gli strumenti per bloccare attacchi di questo tipo esistono anche senza rivedere l’architettura di Internet.
Peró voglio far notare un problema piú subdolo:
Supponiamo che Firefox e Google, che sono in teoria le piú sensibili al problema, decidessero di disattivare di default tutti i javascript, o di rivedere i permessi di javascript all’interno del browser creando una “camicia di forza” che permette al javascript solamente di accedere al proprio sito internet. Cosa succederebbe?
Che molti javascript benigni smetterebbero di funzionare. Nell’immaginario dell’utente comune significherebbe che questi browser sono difficili da usare e browser rivali potrebbero farsi strada togliendo quote di mercato a firefox e google.
Ne consegue, che anche loro sono prigionieri della situazione, l’unico modo sarebbe un accordo tra tutti i produttori e comunque la soluzione non dovrebbe diminuire le funzionalitá odierne, altrimenti si potrebbe sempre fare avanti qualche rivale che ruba quote di mercato.
Paradossalmente questo scenario renderebbe Internet meno sicura.
Lo sono, ma in questo caso non c’entrano niente.
Lo é, ma in questo caso non c’entra niente. A parte il fatto che le connessioni criptate hanno reso internet piú sicura.
Lo é, ma ancora una volta, non c’entra niente con l’argomento di cui stiamo parlando.
A meno di bug, questo tipo di attacco (Man in the Middle) credo che ormai sia abbastanza raro, in caso di connessione criptata é molto difficile da mettere in piedi. Ma comunque anche quest’argomentazione é OT, perché non c’entra niente col bug che proponi.
E’ il progetto originario, il web é sempre stato centralizzato. E’ vero che a cavallo tra gli anni 90 e 2000 c’é stato un movimento che favoriva le connessioni p2p, ma il progetto principale di Internet é questo.
Che questo convenga alle grosse multinazionali e che le cose siano andate diversamente da come ci si aspettava é vero, ma questo é ancora un altro argomento.
Si lo sono, immagino che prima o poi arriveremo all’obbligatorietá delle SRI (Subresource Integrity), come si é fatto per l’HTTPS, ma per arrivarci credo ci debba essere uno storico di exploit che si risolvono in questo modo. Again, siamo fuori tema.
In generale, l’informatica non procede secondo il modello “a cascata”, dove si prevede tutto a monte e poi tutto procede correttamente, ma é un continuo work-in-progress dove si parte da un progetto e questo viene corretto e rimodulato strada facendo.
Non avrai mai un’Internet perfetta, ci saranno sempre problemi che vengono risolti e ogni soluzione genererá nuovi problemi e nuovi attacchi. Che ci siano grandi interessi in gioco é vero, ma credo che presumere che ci sia malizia in ogni cosa sia un approccio sbagliato che puó dare soddisfazione nel corto raggio, ma che alla lunga porta fuori strada.
[quote=“Shamar, post:18, topic:2899”]
Spiegami, per favore: gli header di cache control che permettono di rimuovere le prove non sono un argomento tecnico?[/quote]
@ale cosa sai dell’interpretazione del protocollo HTTP da parte dei browser?
Sai con quale facilità questi header possono essere usati per nascondere un’attacco?
Se sì, ci vuoi illuminare su come distribuisca contenuti su domini di terze parti via HTTPS?
Sei proprio sicuro che sia Off-Topic?
@ale hai capito che sto parlando della centralizzazione prodotta da cloud e CDN?
Hai chiaro come funziona?
Sono MitM applicati su scala planetaria con il consenso dei siti Web ma all’insaputa dei visitatori.
Se ti autentichi su un sito proxato da Cloudflare, lui può associare la tua identità a tutti i contenuti che serve per tutti gli altri siti internet. E ti può attaccare attraverso un sito internet del tutto ignaro, modificando le comunicazioni in transito.
Sei proprio sicuro sicuro sicuro che sia un’altro argomento?
Hai mai visto un sistema perfetto?
Hai letto What is Informatics?: sai benissimo che non credo nella perfezione.
Cos’è questo, benaltrismo InfoSec?
Qui abbiamo una falla di sicurezza colossale installata sui PC di miliardi di persone.
Perché pensi che il Governo Russo stia usando gli attacchi di cui tu neghi l’esistenza?
Prendo atto che a te va bene così.
Per curiosità, che software sviluppi? Posso leggere le loro EULA e/o SLA?
Perché per me, se la libertà e la sicurezza degli utenti del mio software è messa in pericolo dal software stesso, io li informo immediatamente, poi mollo tutto e correggo il problema. Tu no.
Problema fondamentale di tutta la giurisprudenza digitale e del GDPR… perciò applico l’evidenziatore.
E considerando che è compito della NSA creare sotterfugi di questo tipo e grazie a Snowden sappiamo che questo compito lo ha sempre adempito, non è adeguato pensare che tutto ciò sia solo un caso — che sia solo paranoia. Sarebbe illogico ed incoerente pensare che non sia in corso una cyber warfare.
Questo implicherebbe che in ambito tecnologico siamo altrettanto fritti come in ambiti politici quali la globalizzazione, l’ineguaglianza, il surriscaldamento climatico. Tutte cose alle quali non basta più un bug report ma per le quali i poteri in gioco fanno in genere come gli pare… Non so se avete mai partecipato ad un IETF meeting. Io si. Inutile contare sull’IETF. Mentre la W3C è molto peggio.
Non è quello lo scopo degli elenchi di interfacce di rete. Servono a realizzare servizi P2P sul web come le videochiamate WebRTC. Cosa del resto scema dato che WebRTC non è riuscita a democratizzare Skype come ci fu promesso, ma ha semplicemente piazzato le ditte predominanti del web al centro del universo anche per la telefonia (dato che solo loro hanno il necessario grafo sociale).
Eccetto se i contenuti sono banali ed il vero scopo è il tracciamento. O nel caso esposto da Shamar, l’oscuramento di attacchi individuali e/o di massa che grazie a Snowden sappiamo avvengono quotidianamente ed ovunque. Non citavo a caso appunto FOXACID e HACIENDA.
Eddai, non dire così che mi viene freddo ai piedi.
Certo se non credi a Snowden, allora puoi pensare così.
Se non vuoi credere al eccellente lavoro di investigazione di Nafeez Ahmed che ci spiega come il pentagono nel 1995 decise di assicurarsi il controllo totale sulle tecnologie. Tutte. Specialmente l’Internet. L’esistenza della cyber warfare è indiscussa ed è iniziata nel 1995, e certamente include da sempre anche i browser web.
Giusto per capirci, io amo la precisione e non mi piace quando si salta di palo in frasca.
Gli header cache control sono degli header tramite i quali si possono settare le impostazioni della cache del browser quando si carica una pagina. Per esempio é possibile impostare che la tal pagina non deve andare in cache, ma anche altro.
Ora, quando io scrivo che non c’entra niente, vuol dire che non c’entra niente con un javascript che viene eseguito nel browser e tenta di eseguire uno scan della rete locale, perché l’argomento qui é il fatto che si ritiene che l’esecuzione di uno script capace di eseguire primitive di rete all’interno del browser sia un bug. Io non credo. Ma ció non toglie, che gli header cache control non c’entrano niente.
Lo ripeto: in questo caso non c’entrano niente.
CDN sta per content delivery network. Di solito le CDN sono configurate come reverse proxy e servono per alleggerire il peso degli accessi su di un sito internet. Servono per fornire servizi di HA (High Availability), ovviamente quando dico reverse proxy, faccio solo un esempio, perché il punto di una CDN é fornire un servizio, mentre il reverse proxy é una probabile soluzione tecnica. Se vuoi possiamo entrare nel dettaglio di cosa succede quando un edge server riceve una richiesta HTTPS, ma questo cosa c’entra con il nostro scriptino in javascript?
Assolutamente niente.
Lo giuro sullo stack TCP/IP
Vabbé, quest’affermazione falla leggere ad un esperto di sicurezza di rete, ma di quelli veri. Quelli che sanno distinguere un load balancing o un reverse proxy da un attacco Man in the Middle.
Non lo conosco, ma in generale io non credo che esista un “Master of Puppets”, credo che ci siano in piedi continue competizioni su diversi piani, quello militare tra le nazioni, quello economico tra le multinazionali. Questi piani spesso si confondono e si mischiano e voilá abbiamo che su internet a volte succedono cose buone e a volte cose cattive.
Non nego che esistano i servizi segreti, i segreti industriali, gente in buona fede, progetti che puntano a liberare il mondo e progetti che puntano a renderlo prigioniero.
Quello che abbiamo di fronte é la somma di tutto questo bordello, e poi ci si mette anche la legge sull’entropia.
Dal 2004 il working mode del WHATWG prevede che i Living Standard recepiscano le implementazioni prevalenti.
Dunque l’unico modo per fixare una falla di sicurezza in uno standard WHATWG è correggerlo in una implementazione e standardizzare l’implementazione.
Mozilla ha fondato il WHATWG.
Dunque il fatto che Firefox implementi gli standard non è una giustificazione, perché partecipa alla scrittura di quegli standard.
Allora non hai proprio capito l’argomento del thread.
Quello è solo un esempio di una vastissima classe di attacchi.
Perdonami se non ripeto qui ciò che ho scritto nei post precedenti. Rileggili tutti con calma e maggiore attenzione perché non è rispettoso nei confronti dei tuoi interlocutori insistere su qualcosa che evidentemente non hai letto o non hai capito. Solo dopo che hai un quadro d’insieme segui i link, e prova gli exploit di esempio.
Se non riesci comunque a capire il problema posso provare a spiegartelo con altri esempi.
Sulle varie cose che secondo te non centrano (segno evidente che non hai capito il bug report e tutto quello che ho scritto qui, probabilmente a causa di una lettura frettolosa e superficiale), se trovo il tempo ti scrivo più tardi o domani.
Ma vedrai che se rileggi tutto dall’inizio con calma (e hai un minimo di esperienza in materia) capirai da solo (e nel caso ti prego di informarmi così risparmio il tempo).
@lynX ti dispiacerebbe rinominare il thread con il titolo del bug report?
Forse quello avrebbe facilitato @ale ad interpretare il suo contenuto. Possiamo anche tradurre il titolo in italiano in modo che sia più accessibile a tutti.
Se preferisci posso farlo io. Se sei contrario, non insisto… era solo un’idea.
@Shamar, lascia stare, va bene cosí.
E’ evidente che non hai una comprensione vasta della problematica.
Il sottoscritto ha una vasta esperienza in linguaggi di programmazione, sistemi operativi unix, network engineering, e backend. Ho quasi 30 anni di esperienza lavorativa documentata nel settore e le mie competenze spaziano dalla programmazione, ai sistemi operativi, ai cloud, alla sicurezza informatica e sulla progettazione di cluster, quindi se permetti qualcosina la so. Ovviamente non posso essere aggiornato su tutto, ma di qui a non avere comprensione della materia di strada ce n’é.
Il finto exploit di esempio, l’ho provato giorni fa, esegue una serie di azioni che sono documentate in qualunque libro di programmazione.
Giusto per essere chiari: se prendo un libro di HTML 5 e mi vado a vedere come aprire un socket posso fare la stessa identica cosa. E’ documentato.
Ora alla luce di questo vediamo di riassumere cosa é successo:
hai scritto del codice di esempio che fa delle cose che sono documentate negli standard ed é possibile trovare in qualunque libro di programmazione.
hai presentato questa cosa come un bug ai programmatori di Chrome e di Firefox, che ti hanno chiuso il bug e ti hanno detto che era una cosa normale, infatti qualunque programmatore abbia studiato la materia sa come fare.
Hai scritto su twitter a due responsabili di firefox che non ti hanno risposto, indovina il motivo.
Quando ti ho chiesto in cosa consisteva il bug hai tirato dentro cose che non c’entrano niente. E ti ho spiegato il motivo per il quale non c’entrano niente. Perché a differenza tua, io le mie motivazioni le spiego, non mi trincero dietro un “siccome sono esperto non ho bisogno di spiegare”, anche se ho tutte le carte in regola per dire una frase del genere, in effetti tu non hai spiegato proprio niente, ho spiegato tutto io.
Ora, nel tuo ultimo post abbiamo anche capito che non sai cos’é un attacco Man in the Middle, o meglio che non ne hai comprensione, quindi é evidente che non sei un esperto di sicurezza e non hai comprensione dei meccanismi di rete che si trovano in gioco.
Quindi, ti ringrazio, ma credo di avere in mente modi migliori di perdere tempo.
A proposito, per l’inglese, non ti preoccupare, vivo all’estero e lo parlo tutti i giorni con i miei colleghi e scrivo anche documentazione tecnica in inglese.
E pensare che volevo solo fare una piacevole discussione tecnica. E anche in questo thread mi fermo qua, perché col prossimo post mi potrei apparecchiare un ban.
@lynX scusa ho aggiornato il titolo del thread senza aspettare la tua approvazione, ma mi sembra evidente che @ale possa essere stato confuso anche dal titolo di questo argomento…
@ale mi dispiace ho cercato di avvisarti che la tua immagine professionale avrebbe potuto risentire di affermazioni affrettate su questo argomento.
Mi metti in una posizione difficile perché non mi piace umiliare colleghi più anziani, ma stai mettendo in dubbio la mia competenza in pubblico, e mentre tu non hai associato al tuo profilo un cognome od un sito internet che permettano di identificarti precisamente, tutti qui sanno che io sono Giacomo Tesio.
Provo a spiegarti con parole più semplici di cosa stiamo parlando.
Il titolo del bug report che scrissi per Mozilla (e che evidentemente non hai letto) è preciso ed esplicativo: Undetectable Remote Arbitrary Code Execution Attacks through JavaScript and HTTP headers trickery.
In altri termini, qualsiasi server web che visiti può eseguire da remoto una vasta varietà di attacchi non identificabili eseguendo programmi personalizzati sulla tua macchina a tua insaputa, impersonandoti presso servizi locali, rimuovendo ogni prova dell’attacco alla fine; il tutto mantenendo perfetta plausible deniability.
Si tratta di un problema architetturale perché questa vasta classe di attacchi sfrutta comportamenti previsti da diversi standard del Web (HTTP, TLS, HTML, JavaScript etc…) che però, combinati opportunamente, costituiscono una backdoor efficientissima capace di veicolare una enorme varietà di attacchi a computer e smartphone.
Attraverso questa backdoor è possibile attaccare in modo sicuro qualsiasi vittima ma, anche potendo rimuovere le tracce, il rischio di essere beccato per l’attaccante non è irrilevante (pur non essendo molto alto) se attacca tutti i visitatori indiscriminatamente. Dunque è buona norma per chi usa questa classe di attacchi servire script innocui alla stragrande maggioranza degli utenti, per poter far passare da paranoiche le poche vittime prescelte qualora dovessero rilevare l’attacco subito.
E chi può attaccare un utente senza che nemmeno questo si autentichi su un proprio servizio?
Chi serve o effettua il reverse proxy/MitM di milioni di siti Web (cloud o CDN) e può dunque correlare IP, UserAgent etc nei log di siti diversi in anche solo uno dei quali l’utente si è autenticato. Ad esempio Amazon, Google, Cloudflare…
Oppure chi distribuisce piccoli cavalli di troia gratuiti agli sviluppatori Web, come pulsanti Like (Facebook), anteprime video (YouTube/Google), strumenti statistici (Google Analytics) etc…
Costoro possono identificare poche vittime, attaccarle in vario modo, rimuovere le prove, e se per caso questi se ne accorgono (cosa piuttosto improbabile) passeranno per paranoici perché milioni di altri utenti non sono stati attaccati.
In questo post ho elencato le risorse di cui l’attaccante può prendere il controllo durante un attacco. Ivi sono anche indicate le mitigazioni più semplici.
In questo post ho provato a fornirti una visione di insieme, ma assumevo che avessi almeno letto il bug report e provato l’exploit.
Ti consiglio di rileggerli alla luce di quanto detto.
No @ale, non puoi aprire socket TCP in HTML5. Sarebbe una follia dal punto di vista di sicurezza!
Chiunque abbia un minimo di esperienza in materia lo capirebbe.
Ti stai confondendo con i WebSocket.
E come fai in altri passaggi, direi che confondi i browser Web con NodeJS. Entrambi eseguono JS, ma le API disponibili, il sandboxing e le problematiche di sicurezza sono completamente diverse.
Ti basti pensare che un utente che voglia eseguire una applicazione NodeJS, la deve prima scaricare, poi installare (checché questo voglia dire) ed infine lanciare.
Invece un utente che visita una pagina Web per leggersi un articolo di giornale, non sceglie di eseguire una applicazione JavaScript, questa viene eseguita automaticamente, a discrezione di chi controlla il sito web (o la CDN).
Da qui derivano le differenze di cui sopra.
Se tu avessi provato a leggere lo script, avresti notato che per individuare le porte aperte prova a caricare un immagine da ciascuna porta e cronometra il tempo prima di fallire. E’ una specie di timing attack: se la porta è aperta, l’errore si propaga in pochi millisecondi, se la porta e chiusa ci mette diversi secondi perché il browser aspetta il timeout.
Se tu hai un libro su HTML5 che spiega come fare queste cose non esitare a condividerlo!
No, purtroppo non avendo capito proprio nulla della questione le tue deduzioni sono completamente sbagliate.
Il port scanner è solo uno degli attacchi possibili.
Ad essere precisi, i russi l’hanno trasformato in uno scanner di applicazioni di sicurezza: non scansiona tutte le porte, cerca dei file specifici, tipici di alcune applicazioni di sicurezza nella propria configurazione di default, per identificare chi le usa e creare un db di queste persone sospette.
E per altro, la cosa più divertente che ti è sfuggita è che se io lancio un port scanning al tuo IP dall’esterno, posso solo vedere aperte le porte aperte del tuo firewall! Il port scanning che il mio attacco effettua è in grado di conoscere le porte aperte su ogni singola macchina della tua rete privata e comunicarle fuori!
Il mio PoC crea un tunnel nella tua rete. E poi fa un port scan da dentro. E potrebbe fare di peggio.
Forse dopo 30 anni, sarebbe utile un ripasso, non credi?
Comunque se vuoi una cronologia iniziale dei fatti la trovi qui
Non include l’adozione dell’exploit da parte dei russi… ma non so la data precisa.
A me è stato comunicato a dicembre 2018.
Quanto a quelli che vedi nel thread Twitter che ho linkato in precedenza, solo uno è un (credo ex) sviluppatore Mozilla: Asa Dotzler, che in realtà ora Senior Product Manager in Mozilla.
Gli altri partecipanti erano Simon Phipps (presidente dell’Open Source Initiative) e Bruce Perens (quello che ha inventato la definizione di Open Source).
O forse ne ho una comprensione maggiore di te.
La differenza fra un attacco Man in the Middle e quello che fa una CDN come Cloudflare non è tecnica, ma contrattuale: nel caso di Cloudflare, il proprietario del sito web cede consensualmente alcuni certificati TLS a Cloudflare (per la precisione, li autorizza a chiederne il rilascio a proprio nome) in modo che Cloudflare si possa collocare in mezzo fra i visitatori del sito ed il sito stesso, cachando i contenuti HTTPS.
In altri termini, dal punto di vista del visitatore che pensa di star comunicando direttamente con il sito Web in modo riservato, Cloudflare è un Man in the Middle. E la questione è rilevante perché Cloudflare è Man in the Middle per milioni di siti Web. Ed è vincolata contrattualmente solo con i proprietari dei siti. E risponde al governo USA.
Dunque può correlare connessioni TCP (tipicamente riusate dal browser), richieste HTTPS ed informazioni di autenticazione fra siti diversi.
Se ancora non ti è chiaro come questo sia rilevante, ricorda che la precondizione per ottenere la plausible deniability è di poter identificare le vittime e poter far veicolare l’attacco a siti di terze parti ignare.
Beh, spero che sia stata quanto meno interessante!
Hai ragione, non avrei dovuto insinuare che ti mancano alcune competenze, perché effettivamente non so niente della tua professione e forse ti sto mettendo a disagio. Ho agito in questo modo, dopo che per diverse volte hai insinuato che non capivo o mi ero confuso mentre mi trovavo purtroppo a constatare che la tua terminologia é fumosa e imprecisa.
Vedi, negli ambienti ai quali sono abituato io la cosiddetta “blaming culture” non é una virtú e quando si parla di cose tecniche non si insinua mai che l’altro non sia competente, ma si sta semplicemente sul pezzo e si parla dell’argomento in sé. Mi dispiace che tu non sia capace di farlo. Ti auguro di crescere un pó dal punto di vista umano.
Una cosa che mi stupisce di questa comunitá forse é proprio questa mania di controllo e onnipotenza che ho rilevato in diversi thread, non mi sarei mai aspettato di trovarla in un ambiente che la aborrisce all’esterno peró poi alcune persone ne fanno metodo all’interno.
Non so se é ancora il caso di entrare nel dettaglio, visto che se ti vai a leggere il bug report che hai creato su Mozilla vedrai che ci sono tutte le risposte delle quali hai bisogno. Ti faccio solo notare delle cose sul significato delle parole. Perché vedi, se stessimo parlando tra junior, ci sta che si é imprecisi, ma quando si ha la presunzione di contestare l’architettura di internet allora si deve utilizzare la terminologia in modo corretto, altrimenti é logico che si venga scambiati per persone che conoscono male la materia.
Io direi che possiamo partire dal significato di bug, visto che quello che hai presentato é un bug report.
Non importa a quale definizione ti rifai, ad un certo punto arriverai sempre alla conclusione che il bug é un errore di progettazione o di scrittura di un software dove ad un certo punto si ottiene un malfunzionamento o un funzionamento inaspettato, indesiderato.
In questo caso immagino, siamo nel caso di un funzionamento inaspettato, il mio punto é che quel funzionamento, non solo non é inaspettato, ma é voluto, tu dici che lo script maligno “prende possesso delle risorse del computer” e ne fai l’elenco, ma quelle risorse non sono “prese”, sono concesse by design ed esistono livelli dove si puó cancellare questa concessione.
Quindi per onestá intellettuale, dobbiamo dire che non é un bug, a meno che non vogliamo cambiare il significato di bug.
Ció non toglie che il comportamento é strano, ma in questo caso dovremmo parlare di progettazione scadente dei dispositivi di sicurezza o di configurazione scadente degli apparati che possono essere scansionati con tale semplicitá.
La soluzione che hai proposto é di disabilitare javascript, che corrisponde a tornare a internet 1.0. Francamente un pó tanto.
Sorvolo sull’atteggiamento da Spectre di James Bond e rimango sulla questione di vocabolario.
Quindi vediamo cos’é un attacco Man in the Middle:
Secondo wikipedia: indica un attacco informatico in cui qualcuno segretamente ritrasmette o altera la comunicazione tra due parti che credono di comunicare direttamente tra di loro.
Quindi, in primo luogo: é un attacco, cioé per poterlo chiamare MITM deve esserci un attacco, ho forti dubbi che i web content provider non siano consapevoli di quello che succede.
Per quanto riguarda gli utenti, le informazioni sono disponibili e il lavoro che fanno i content delivery network non é secretato.
Infatti, se io mi collego sul sito tal dei tali, proxato da un CDN, parlo a tutti gli effetti (anche legali) con quel sito. Se cosí non fosse non si potrebbero affittare neanche i data center, perché se io mi servo di un computer che non é nella mia disponibilitá fisica potrebbe succedere che il data center mi cambia i dati nel mio hard disk. Forse che dovremmo buttare giú tutti i data center del pianeta?
Quindi la cessione di certificati TLS non solo é legittima, ma é anche normale, é quello che avviene quando si configura una batteria di server dietro un load balancer, il CDN puó essere interno o esternalizzato, ma la tecnologia esiste e non é un MITM.
Intendevo finto, in quanto non é relativo ad un bug. Ma ad una progettazione/configurazione scadente degli apparati che vengono attaccati.
Il mio punto é che lo standard prevede che si possa fare. Quindi non é una scoperta, non é una cosa segreta é documentato.
Credo di avere giá scritto sopra che l’ho letto giorni fa. Tenta di aprire una connessione http su delle macchine, non é niente che non possa essere gestito a livello di routing.
Non ho letto lo script. Stai dicendo che questo script é capace di essere lanciato all’interno di un browser e quindi:
a) connettersi ad un’altra macchina in rete locale, scansionare il loro hard drive e trovare file specifici
oppure
b) connettersi ad un’altra macchina in rete locale e cercare se c’é qualche file tipo il welcome di nginx?
E successivamente questo script salva questi dati sul server remoto?
Diciamo che se non chiudi la porta di casa chiunque puó entrare e scansionare, comunque concordo che anche la sola possibilitá di leggere informazioni é un security concern. Ma non é un problema di struttura.
Infatti non mi é sfuggita, anzi, é un’ovvietá, lo scan avviene dall’interno del browser, cioé nella macchina locale. Ma é possibile isolare questi tipi di scan a diversi livelli.
Effettivamente ho sbagliato il conto. Sono 25. E credimi, se sono ancora qui é proprio perché studio ogni giorno.
E tutti quanti ti hanno detto in vari modi che non é un bug dei browser.
Anche a te e compra un vocabolario
Sono certo che Giacomo ha delle ottime qualitá tecniche, e paradossalmente se un giorno avessimo la fortuna di lavorare insieme forse andremmo anche d’accordo, ma migliorerebbe molto se fosse capace di porsi in modo migliore.
Io conosco l’argomento, e posso spiegarmi, ma trattare con sufficienza gente che sta cercando di imparare non sarebbe una buona qualitá in un trainer.
Cmq, al di la della discussione, quello che secondo me potevi o potresti fare é una richiesta di aggiungere una feature.
Questa feature dovrebbe essere relativa a tenere gli script remoti un una jail o container dove si possono definire con precisione i permessi, il ruolo e le autorizzazioni che ha lo script remoto.
Ti prego, rileggicon maggiore attenzione.
Ho proposto di rendere l’esecuzione di JS, WASM e la gestione di alcuni meta opzionale disabilitata all’inizio e da abilitare sito per sito. E nemmeno basta! Servono anche tutte le altre modifiche che ho elencato.
Non sarebbe affatto un ritorno al Web 1.0, perché potresti riabilitare JS su un sito che lo necessita con un click, come puoi fare su Chrome (ma non su Firefox) se modifichi la configurazione. E le altre mitigazioni suggerite, renderebbero l’esecuzione più sicura.
Pochi giorni fa David Kayne ha spiegato che questo tipo di strumenti di sorveglianza permette detenzioni arbitrarie o ingiuste, torture ed uccisioni extra giudiziali.
Non ha detto, perché non essendo un informatico competente non sa, che fra questi strumenti di sorveglianza capaci di creare prove fittizie sul PC o lo smartphone di un nemico politico vanno elencati anche tutti i maggiori browser Web (inclusi appunto Chrome e Firefox).
Se per te la vita umana vale meno di queste mitigazioni, credo che non abbiamo molto da dirci.
E tutti quanti stanno sbagliando.
Il re è nudo @ale.
Io sono solo il bambino che lo ha detto per prima.
Ma prima o poi tutti inizieranno a ridere (o piangere). E non sarà contro di me che se la prenderanno.
Si chiama sandboxing è i browser lo fanno già. Non basta.
Quanto ai MitM ho già scritto tutto, se per te il fatto che una parte sia consenziente non lo rende un attacco per l’altra non so cosa dirti.
Sì sì come funziona è pubblico e documentato (ho mai scritto i contrario? Secondo te perché parlo di bug architetturale?) ma dire che chi non sa cosa sono le CDN non merita libertà e sicurezza è victim blaming. Molto libertario, complimenti!
Così come sostenere che se una rete privata viene compromessa attraverso un browser la colpa non è di chi ha scritto il browser ma di chi ha scritto o configurato i servizi di rete confidando che i firewall servano a qualcosa.
Guarda, io NON sono un esperto di sicurezza.
Sono solo un hacker con 20 anni di esperienza pratica su queste materie.
Sono una persona curiosa che pensa con la propria testa ed ha l’onestà intellettuale di affrontare i problemi. E la cosa terribile è che se un programmatore come me è il primo ad evidenziare vulnerabilità architetturale di questo livello, tutti gli esperti di sicurezza del pianeta dovrebbero farsi un serio esame di coscienza. E chi li paga dimezzarne gli stipendi.
La vulnerabilità più grave che ho scoperta non è quella tecnica, ma quella politica.
Miliardi di persone si fidano per il proprio IT di incompetenti e/o persone in mala fede.
E non hanno gli strumenti culturali per distinguere chi li vuole aiutare e chi li manipola.
Ti chiedo scusa, ma ti devo far notare che ho cominciato ad avanzare dubbi sulle tue competenze solamente quando hai insistentemente affermato che non capivo ed ero confuso e praticamente tu insinuavi che fossi io a non averle. A quel punto mi sono visto costretto a farti notare che facevi confusione sui termini. Peró credo che si noti chiaramente dal dibattito che anche se con le dovute imprecisioni e alcuni deliri di onnipotenza sei comunque una persona molto preparata. Non mi sognerei mai di affermare che non sei professionalmente preparato per il lavoro che fai. Anzi, se devo essere sincero ritengo che sei al di sopra della media.
Come ben saprai in molte culture, come ad esempio quella anglosassone é prassi tenere separata la vita personale da quella professionale. In questo contesto non trovo corretto fornire il mio profilo professionale.
Tralaltro non ho alcuna intenzione di avere ragione in forza della mia professione, preferisco che ti bastino i miei argomenti. Se non sono sufficienti puoi avere ragione qualunque sia la mia professione.
Queste sono le tue parole nel bug report:
Well, given the severity of the issue, as a first step I would release an emergency fix that disable JavaScript (and Meta Refresh) without looking at the user settings.
Then I would deploy a mid term fix so that:
Meta Refresh and JavaScript are disabled by default
Both can be enabled on a per website basis,
SubResource Integrity is made mandatory (at least for JavaScript): page
For each URI record SHA256 of last downloaded content and warn the user if the page change their SRI
Warn the user about scripts served with suspect HTTP headers
Per tua comoditá ti ho messo in grassetto il punto dove affermi che si deve disabilitare JavaScript
Mi riferivo alla possibilitá di gestire i permessi dalle impostazioni di Firefox, di renderle piú granulari.
Sfortunatamente vale per qualunque cosa tecnica, anche per i meccanici delle automobili. Chissá, magari in futuro cambierá.
PS: per la blaming culture, mi riferivo al tuo maldestro tentativo di umiliarmi, non al victim blaming nei confronti degli utenti.
Comunque, mi hai fatto venire in mente una cosa che forse qui é OT, peró, potrebbe essere un argomento politico:
Gli script remoti che vengono lanciati nei browser, vengono lanciati senza esplicito permesso dell’utente.
Quando in questi termini si é parlato di dati, si é arrivati alla legge europea che obbliga i siti internet ad autorizzare esplicitamente l’utilizzo dei cookie.
Si potrebbe sostenere che si deve autorizzare esplicitamente e legalmente il lancio di un javascript nella propria macchina. In quanto, il server remoto sta usando risorse delle quali non detiene la proprietá.
Forse potremmo chiedere ai pirati europei se é possibile elaborare questa cosa
Sono felice che siamo stati capaci di uscire da questo impasse senza bisogno di venire moderati da terze persone.
Non ho competenze legali, ma credo che sarebbe interessante se riuscissimo a coinvolgere i pirati europei, in una proposta che obbliga i siti visibili in Europa ad autorizzare esplicitamente un server all’utilizzo di risorse locali di una macchina specificando (ad esempio) la lista delle risorse che verranno coinvolte. E’ solo un’idea, immagino che tu avendo studiato in profonditá la questione potresti essere piú preciso.
Sono felice anche io, ma non credo ci fosse il rischio che qualcuno “ci moderasse”.
Sono felice perché a volte scontrarsi è inevitabile, ma fra persone intelligenti può diventare un buon modo di incontrarsi e conoscersi. Alcuni dei miei amici più in gamba li ho conosciuti proprio così.
Spero sinceramente che possa accadere anche qui.
Dunque scuse accettate: ora pensiamo a come possiamo risolvere il problema!
Credo che non funzionerebbe per una serie di ragioni tecniche (troppo complicato, etc…) e politiche (richiederebbe il ban di cloud e CDN extracomunitarie, che verrebbe considerata protezionismo e attaccata come “volete dividere internet come Putin”).
Inoltre non risolverebbe il problema: e i siti fuori dall’Europa?
Però mi hai fatto venire in mente un’idea interessante: una PdL che, analogamente al GDPR, regolamenta le caratteristiche di sicurezza minime per un browser distribuito sul territorio europeo.
Potrebbe dire: o semplicemente rimuovete tutte queste feature insicure (strategia alla NetSurf), o le rendete sicure e ne date un controllo granulare, usabile e comprensibile agli utenti (aka tutte le mitigazioni che propongo e altre che ci venissero in mente).
Una legge del genere avrebbe un impatto straordinariamente positivo per il Web.
Immagina tutti quei siti di contenuti che usano JS solo perché possono, appesantendo la navigazione di mega e mega, tracciando l’utente etc… non potendo più assumere che il visitatore li visiti con JS (o WASM) abilitati, riscoprirebbero l’accessibilità come un fattore qualificante del loro brand, e probabilmente anche il web semantico e il progressive enhancement.
E i browser stessi sopperirebbero all’assenza di JS con nuovi elementi dichiarativi capaci di rappresentare contenuti SENZA permettere tracciamento. Abbiamo esplorato questa possibilità con un amico che sviluppa un browser web chiamato Odysseus. Adrian ha iniziato con lo sviluppo di un browser chiamato Memex (nome da intenditori ) che ignora bellamente gli standard e prova a riprodurre gli ipertesti che JavaScript permette, senza JS e senza essere una piattaforma applicativa.
Purtroppo gli hacker sono pochi e il lavoro è tanto.
Ma a quanto ne sappiamo dall’analisi fatta, si può fare e verrebbe piuttosto bene.
Un web fatto di ipertesti potenti e belli come quelli di adesso, ma NON una piattaforma applicativa distribuita.
Ah, finalmente si torna a parlare di qualcosa on-topic.
Magari, ma conosciamo gli avvocati. Se integriamo lo scripting nel GDPR avrebbe solo per conseguenza che devi dare a tutti i siti il permesso di eseguire codice + raccogliere dati, e poi le cose continuano esattamente come adesso.
Mentre questo problema non esisterebbe se fosse in vigore #ObCrypto.
Gli scandali informatici sono ormai così assurdi e folli che tutti alzano le mani e non fanno più nulla.
Mi pare di ricordare che tu ed io abbiamo avuto una conversazione simile qualche mese fa.
