Sarebbe possibile avere un osservatorio javascript, un sandboxing più severo e un CSP più severo (Content Security Policy) per Tor?

L'Osservatorio SSL funziona inviando il certificato SSL a una terza parte per confermare che è valido. Fare lo stesso per Javascript ha due problemi.

1. Le prime priorità di TOR sono anonimato e privacy. Se il browser TOR inviava tutti i Javascript a una terza parte per convalidarlo, quella terza parte sarebbe in grado di creare un profilo di utilizzo detraile. Certo, potrebbero esserci modi per ovviare a questo problema, ma semmai aumenterà la superficie di attacco per deanonymizzare gli utenti.
2. Non puoi eseguire automaticamente la scansione di Javascript per cattiveria. Ci sono troppi modi per nascondere comportamenti scorretti. Se fosse così facile, ci sarebbero i plugin del browser per farlo (in effetti ci sono, ma i loro tassi di rilevamento sono abissali). Tutto ciò che potrebbe fare è mantenere una whitelist di codice Javascript innocuo noto. Ma ciò richiederebbe un team di specialisti della sicurezza per controllare manualmente ogni script. Potrebbe valere la pena di uno sforzo per alcuni siti web tradizionali molto frequentati. Ma questi di solito non sono il tipo di siti web a cui l'utente TOR medio è interessato.

Il sandboxing più rigoroso per impedire a Javascript di fare cose che non dovrebbe fare è ovviamente sempre una priorità. Nessuna di quelle cose che hai menzionato dovrebbe essere possibile secondo le specifiche di Javascript, quindi se è possibile, è un bug che dovrebbe essere risolto nella mainline di Firefox e non solo nel browser TOR.

Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy)... similar to EFF's SSL observatory

Penso che devi prima decidere quale tipo di attacchi vuoi proteggere. L'utente malintenzionato potrà sostituire il contenuto di siti di terze parti inclusi nel sito principale (ad es. Jquery.org) o sarà in grado di modificare anche il sito principale?

Se l'attaccante è solo in grado di compromettere i lati di terzi, potrebbe funzionare un CSP rigoroso e qualcosa come un osservatorio JavaScript, perché proibisci l'inclusione di script di terze parti o limitalo a uno script ben noto (vedi anche hash per script-src implementati in Chrome 46).

Ma se l'hacker è anche in grado di modificare il contenuto del sito principale, questo approccio probabilmente aiuterà solo per i pochi siti che non hanno script in linea, nessuno script dipendente dall'utente e dove lo script cambia solo raramente. In pratica, JavaScript viene modificato molto più spesso di un certificato e spesso si hanno casi in cui il codice JavaScript fornito a un utente è adattato all'utente, cioè dipende dalla sessione, dall'account ecc. Questo non è vero solo per lo script inline ma anche per lo script incluso con il tag dello script. Inoltre, ci sono molti piccoli frammenti di script inclusi in attixxx su onXXX (vale a dire onclick="dothis();" ) in cui non solo il codice di script stesso è rilevante, ma anche dove questo codice viene utilizzato nell'HTML. Quindi un osservatorio non sarebbe di aiuto per tutti tranne alcuni siti principalmente statici.

NoScript XSS filter is flawed.

Tutti i filtri XSS sono limitati come tutte le soluzioni antivirus. È impossibile distinguere in modo affidabile tra buono e cattivo con le informazioni limitate che questi filtri hanno su ciò che può essere buono o cattivo per un sito specifico. O bloccano troppo (falsi positivi) o mancano qualcosa (falsi negativi). Nel primo caso l'utente spegnerà il filtro e in quest'ultimo caso non offrirà una protezione completa.

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc.

Sì, non considererei ottimale l'attuale architettura di sicurezza di Firefox e penso che Chrome offra una protezione migliore contro gli exploit che cercano di uscire dal browser. D'altra parte, per quanto ne so, Chrome non fornisce l'API necessaria per i controlli completi eseguiti da NoScript (ad es. Prevenzione XSS, rilevamento clickjacking ...).

Un altro approccio sarebbe quello di eseguire il sistema operativo con il browser stesso all'interno di una macchina virtuale in modo che l'utente malintenzionato non solo scappasse dal browser ma anche dalla VM per ottenere le informazioni pertinenti. Ogni livello di separazione rende più difficile l'attacco.

Could someone explain parts of the FBI's Firefox 0-day?

Dalle informazioni pubbliche disponibili sembra che abbiano usato Javascript per innescare un bug nel browser per iniettare il codice shell che poi poteva fare qualsiasi cosa con le autorizzazioni dell'utente, incluso l'accesso a hostname e MAC e l'invio di queste informazioni al server degli hacker . Non riesco a vedere dalle informazioni pubbliche quale sito hanno compromesso e se il sito dipendeva dallo script, se utilizzava script in linea ecc. Quindi non è noto se il tuo approccio con l'osservatorio e CSP avrebbe protetto l'utente in questo caso.