Perché JavaScript è "sicuro" per essere eseguito nel browser?

Lo standard è progettato per essere sicuro. L'implementazione potrebbe non essere.

Il browser isola JavaScript, poiché viene eseguito all'interno di un processo del browser stesso. Non può fare nulla che non sia permesso dall'interprete JavaScript del browser o dal compilatore JIT. Tuttavia, a causa della sua complessità, non è affatto raro trovare vulnerabilità che consentano a JavaScript di compromettere il browser e ottenere l'esecuzione di codice arbitrario con i privilegi del processo del browser.

Poiché questi tipi di bug di sicurezza sono così comuni, molti browser implementeranno una sandbox. Questo è un meccanismo di protezione che tenta di isolare un processo di browser compromesso e impedire che causi ulteriori danni. Il modo in cui funziona la sandbox dipende dal browser. Firefox ha un sandboxing molto limitato, mentre Chrome e Edge hanno un sandboxing significativo. Tuttavia, nonostante questa difesa approfondita, le vulnerabilità dei browser possono spesso essere combinate con vulnerabilità di escape sandbox.

How is it safe?

Non lo è. O più esattamente è sicuro quanto l'implementazione del browser. I browser (incluso il loro motore JavaScript) sono software complessi, con aggiunte regolari di nuove funzionalità, perché gli utenti li desiderano.

Ciò significa che, anche se i più noti hanno una procedura di qualità per testare il loro codice contro vulnerabilità note, esiste sempre il rischio di un difetto non rilevato nell'implementazione di una funzione.

Attualmente, il modo accettato è che non appena viene rilevata una violazione, viene rilasciata una nuova versione contenente una correzione. Ma tra la scoperta della violazione e l'installazione della correzione, il browser è vulnerabile. Questo è il motivo per cui è consigliabile mantenere aggiornato il proprio browser, per essere solo esposto a zero-day vulnerabilità.

È vero che a livello JavaScript i browser sono progettati per sandbox il codice in esecuzione (principalmente non esponendo alcuna API pericolosa), ma JavaScript è una lingua molto complessa da analizzare e eseguire .

ECMAScript è lo standard dietro JavaScript, a causa dell'enorme inflazione di marketing intorno ai linguaggi di programmazione per principianti che stiamo vivendo oggi, l'ECMAScript si sta aggiornando rapidamente e introduce funzionalità sempre più complesse da implementare per un runtime.
Questo, a sua volta, allarga la superficie di attacco e permette ai bug di insinuarsi .

Un esempio meraviglioso è il recente lavoro di Patrick Biernat , Markus Gaasedelen , Amy Burnett per il pwn2own 2018.

link

Il blog descrive la scoperta di un 0day che consente l'esecuzione di codice arbitrario in WebKit e il modo in cui viene utilizzato per sfruttare un altro 0day nel gestore finestre macOS per uscire dal sanbox in cui Safari è in esecuzione (è un macOS sandbox, non quella di Safari) per inoltrare a "root" e possedere il sistema.
Per farla breve, semplicemente visitando un collegamento mentre JavaScript è abilitato, un sistema macOS può essere completamente compromesso senza che un singolo problema sia visibile all'utente.
Ecco come JavaScript può essere sicuro: sicuro come un software complesso come può essere JSCore di WebKit.
Ecco perché si consiglia agli utenti che richiedono un'elevata sicurezza di disabilitare JavaScript (che è un requisito abbastanza comune in DarkWeb, ad esempio).

La vulnerabilità in WebKit rilevata dagli autori sopra è una condizione di competizione tra il nuovo garbage collector e la funzione array.reverse : se il GC inizia a marcare un array mentre viene invertito, potrebbe portare a un UAF (Use After Gratuito) exploit. Il marchio viene fatto sequenzialmente sull'array, supponiamo che il GC sia proprio al centro dell'array quando questo è invertito, quindi la seconda metà non viene mai contrassegnata e quindi eletta per la raccolta, risultando in un UAF (l'oggetto stesso dell'array non viene raccolto, solo il suo elemento).

Come viene utilizzato un UAF per rendere più potenti exploit primitive che possono portare all'esecuzione di codice arbitrario è più o meno una variazione delle stesse tecniche: prima un oggetto interessante viene allocato nello spazio appena liberato (es. un array) quindi un La primitiva RW viene creata (ad es. Modificando il limite dell'array) e infine gli opcode arbitrari vengono scritti in memoria (ad esempio in una pagina JITted).
I dettagli per questo particolare 0day sono nel blog collegato.

La parte interessante è il modo in cui è stato trovato questo 0day: dal momento che WebKit è una revisione del codice così ampia e approfondita è impossibile senza grandi sforzi, quindi è stato impostato il jitter automatico.
Questo deve farci riflettere sul fatto che quando abbiamo centinaia di milioni di linee di codice, è molto difficile fare in modo che ognuno si comporti bene rispetto a tutti gli altri.

Come affermato in altre risposte, ogni browser ha il proprio motore di script progettato per l'esecuzione di sandbox JavaScript e ogni motore tenta di limitare la funzionalità JavaScript che potrebbe portare a comportamenti dannosi.

Ma di regola JavaScript non è mai stato al sicuro nel browser. Gli sviluppatori di codici dannosi sono costantemente alla ricerca di modi per sfruttare il funzionamento di ciascun motore e le funzionalità JavaScript disponibili per raggiungere obiettivi dannosi.

Nei primi anni JavaScript era piuttosto pericoloso all'interno del browser. Ora è una corsa costante tra gli sviluppatori di codici dannosi e gli sviluppatori di browser / motore e alla fine gli sviluppatori maligni vincono sempre, anche se solo per poco tempo. Quindi JavaScript può difficilmente essere definito sicuro. "Dovrebbe essere sicuro per ora" è un modo più accurato per metterlo.

JavaScript is pretty powerful

È per questo che molti utenti lo considerano pericoloso e lo bloccano usando le estensioni del browser. JavaScript consente ai siti Web di tracciare gli utenti in modi che non sono possibili senza includere l'identificazione degli utenti dopo che hanno cancellato i loro cookie mediante l'impronta digitale del browser. Molte delle nuove API Web come WebUSB consentono cose che non sono affatto sicure, ma i browser richiedono l'autorizzazione dell'utente quando accedono a API non sicure come USB e fotocamera.

È sicuro rispetto al codice eseguibile a livello di macchina, come gli usi di ActiveX.

Un programma di codice macchina ha accesso assoluto a qualsiasi interfaccia che il sistema operativo e le librerie forniscono a qualsiasi programma in esecuzione con tale account utente, è solo VERAMENTE limitato in ciò che può fare da ciò che l'hardware e il sistema operativo lo limitano - essenzialmente facendo un programma così potente come l'utente che lo esegue. Potrebbero esserci strumenti che tentano e limitano l'intercettazione di alcune delle interfacce fornite, ma è difficile fermare un programma consapevole di tali misure per eluderle.

L'interprete javascript fa parte del browser e viene scritto in modo da offrire solo al programma che sta eseguendo le interfacce e i poteri che vuole offrire loro.

JavaScript è "relativamente sicuro", ma non "assolutamente sicuro". Qualsiasi codice eseguito sul tuo sistema potrebbe essere pericoloso. Non esiste un sistema perfettamente sicuro, tranne quello che non ha mai usato. JavaScript è più sicuro di un dispositivo USB sconosciuto nel tuo computer e più sicuro di un file binario scaricato da un sito Web ombreggiato o di un allegato di e-mail sospetto, e molto più sicuro di alcuni degli script che troverai sui siti web che ti dicono di copia e incolla nella tua shell.

Ha funzioni di sicurezza: una sandbox per isolare il processo, un'API relativamente limitata che ha vincoli di sicurezza per evitare l'esecuzione di istruzioni arbitrarie del computer e controlli di sicurezza intesi a limitare l'esposizione di dati sensibili come impronte digitali o condivisione di dati tra domini . Questi sono in cima ai controlli del sistema operativo applicati al binario del browser per limitare il comportamento scorretto e alle applicazioni anti-virus che possono aiutare a fermare tali attacchi.

Tuttavia, non è assolutamente sicuro. I bug nel motore di runtime del browser, il browser stesso, l'antivirus o persino il processore stesso possono compromettere la sicurezza di JavaScript. Il sistema è sicuro solo quanto la sua sicurezza più debole. La sicurezza di JavaScript è principalmente intesa a prevenire exploit "casuali" (come ad esempio un 8 anni di apprendimento di JavaScript per la prima volta e la scrittura accidentale di un exploit), ma non ha alcuna possibilità contro attaccanti dedicati. JavaScript è abbastanza complicato da renderli bug, forse in modi strani e inaspettati.

Quelli con esperienza nell'hacking, nella verifica delle penne e nella sicurezza possono, e lo fanno, sfogliare il codice sorgente, eseguire il debug degli eseguibili e fare qualsiasi altra cosa per provare e trovare chinks nell'armatura. I punti deboli dell'implementazione di JavaScript. E JavaScript è abbastanza grande da poter esistere prima, dal momento che è virtualmente impossibile persino automatizzare tutti i possibili test che troverebbero questi bug.

In generale, qualsiasi tipico script che potresti eseguire su un sito web tipico è probabilmente "sicuro", specialmente quelli collegati ai principali motori di ricerca. Tuttavia, una volta che si inizia a scendere dai sentieri battuti, è incredibilmente probabile che il sistema venga compromesso ad un certo punto se c'è anche un singolo punto debole. Ci vuole solo un ottimo exploit, o qualche volta due o tre in tandem, per occupare completamente un sistema.

Così com'è, abilita JavaScript solo per i siti di cui ti fidi (io personalmente uso NoScript per questo scopo), tieni sempre aggiornato tutto il tuo software e presta sempre attenzione agli avvisi del browser come certificati non validi e così via. Anche così, non sarai sicuro al 100%, ma parteciperai attivamente alla tua strategia di mitigazione.

Non c'è nulla di intrinsecamente sicuro su JavaScript, in molti modi è meno sicuro rispetto ad altre lingue:

• dichiarazione eval
• digitazione dinamica

È la sandbox in cui il browser esegue il codice JavaScript che fornisce la sicurezza. Consulta la documentazione sulla sandbox di Chrome qui , nota che non vi è alcun riferimento a Script JavaScript o ECMA.

Oggi la maggior parte dell'esecuzione di codice nel browser è scritta in JavaScript. Con l'avvento di WebAssembly , probabilmente vedremo la piattaforma del browser passare dal blocco principalmente in lingua singola di oggi (come un mainframe del passato) su una piattaforma aperta in cui è possibile utilizzare qualsiasi linguaggio compatibile con WebAssembly. Ciò, in un certo senso, dimostrerà che JavaScript non è particolarmente sicuro / speciale, poiché a quel punto molte lingue verranno eseguite nel browser. Tutte queste lingue utilizzeranno la sandbox fornita dal browser per l'esecuzione.

Questa risposta affronterà due punti sollevati nella domanda e una "funzione" del browser non sollevata nella domanda.

JavaScript has certain limitations such as preventing reading and writing to disk

tale limitazione non esiste tecnicamente nei browser Chromium / Chrome in cui è definita requestFileSystem , che scrive direttamente sul disco; ovvero la cartella File System della directory di configurazione di Chromium / Chrome sul file system degli utenti.

Vedi Come scrivere nel file (directory dell'utente) utilizzando JavaScript?

and not allowing access to other browser windows or domains.

Se viene aperto un window da un window aperto, è possibile utilizzare la comunicazione tra window s, inclusi, ma non limitati a, postMessage , MessageChannel , SharedWorker o semplicemente query parametri di stringa.

Vedi Come posso caricare un web worker condiviso con uno script utente?

Un altro punto non menzionato nell'OP che deve essere sollevato qui specifico per Chromium / Chrome è il fatto che l'implementazione SpeechRecognition dell'API Web Speech in quei browser registra la voce dell'utente (identificatore biometrico) e invia quella registrazione a un servizio remoto, senza informare direttamente l'utente di ciò che sta avvenendo. Non è immediatamente chiaro se le registrazioni vengono conservate (per sempre) dal "servizio web" non rivelato o "cancellato" a un certo punto.

Vedi webkitSpeechRecognition invia l'audio registrato a un servizio Web remoto per impostazione predefinita?

È sicuro perché è stato progettato per essere sicuro. O almeno è sicuro al punto in cui un "JavaScript non molto formale è piuttosto potente" suggerisce che probabilmente è sufficientemente sicuro per rassicurarti. In pratica, nessun software è perfettamente sicuro, quindi è una questione di laurea. Javascript è abbastanza sicuro che la maggior parte delle aziende è disposta a consentire ai dipendenti di visitare i siti Web utilizzando l'hardware aziendale.

JavaScript è progettato per impedire agli aggressori di accedere ai tuoi file o a qualsiasi informazione privata. Ad esempio, ha il supporto per impedire a uno script su un sito di guardare i dati da un altro sito (noto come un attacco cross-site).

Naturalmente, questo non è perfetto. C'è stato un recente spavento con Spectre e Meltdown , un paio di exploit che facevano affidamento su un difetto in alcuni processori per liberarsi dalla sandbox JavaScript in esecuzione. Doveva essere corretto con alcuni hack di software piuttosto brutti da coprire per i processori imperfetti.

Ma in generale, è "sicuro" eseguire tali script perché molti esperti di sicurezza hanno speso un sacco di tempo per assicurarsi che la sensazione di sicurezza sia giustificata. Ma tutto dipende dal tuo modello di minaccia. Se avessi miliardi di dollari sulla linea, potresti non volere nemmeno fidarti della sicurezza di JavaScript!

Quindi la vera domanda è qual è il tuo bar per "sicuro?" Prendi in considerazione Windows per sicurezza? Che dire di Internet Explorer ? Adobe Acrobat Reader ? OpenJPEG ? Il kernel Linux ? OpenSSL ? La sicurezza e l'usabilità sono sempre in disaccordo. Devi usare qualcosa (o forse no. Gli Amish non sono stati colpiti da uno 0 giorni ancora ... a meno che non contassi un nuovo ceppo di influenza) Per capire davvero se puoi chiamare qualcosa di "sicuro" o Non è necessario un modello di minaccia, che definisca come qualcuno potrebbe attaccarti e un modello di usabilità che definisce quale usabilità è necessario ottenere mitigando il modello di minaccia. Senza di essi, dobbiamo leggere nelle tue parole e nella tua storia per indovinare cosa significa "sicuro".