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

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

Perché 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 del 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 ed Edge hanno un sandboxing significativo. Tuttavia, nonostante questa difesa in profondità, le vulnerabilità del browser possono spesso essere combinate con le vulnerabilità di fuga dalla sandbox.

Come è sicuro?

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

Ciò significa che, anche se quelli ben noti hanno certamente una procedura di qualità per testare il loro codice contro le vulnerabilità note, esiste sempre il rischio di un difetto non rilevato nell'implementazione di una funzionalità.

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, motivo per cui si consiglia di mantenere il proprio browser aggiornato, in modo da essere esposto solo allo zero-day vulnerabilità.

È vero che a livello di JavaScript i browser sono progettati per eseguire il sandboxing del codice in esecuzione (principalmente non esponendo alcuna API pericolosa), ma JavaScript è un linguaggio molto complesso 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 sperimentando oggi, ECMAScript si aggiorna rapidamente e introduce funzionalità sempre più complesse da implementare per un runtime. Questo, a sua volta, amplia la superficie di attacco e consente agli insetti di insinuarsi .

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

http://blog.ret2.io/2018/06/05/pwn2own-2018-exploit-development/

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

Il vulnerab ility in WebKit scoperto dagli autori sopra è una condizione di competizione tra il Garbage Collector appena introdotto e la funzione array.reverse : se il GC inizia a contrassegnare un array mentre viene invertito, potrebbe portare a un UAF (Usa dopo gratis) exploit. Il segno viene eseguito in sequenza sull'array, supponiamo che il GC sia proprio al centro dell'array quando questo viene invertito, quindi la seconda metà non viene mai contrassegnata e quindi eletta per la raccolta, risultando in un UAF (l'oggetto dell'array stesso non viene raccolto, solo il suo elemento).

Il modo in cui un UAF viene utilizzato per rendere più potenti primitive di exploit 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 (ad esempio un array) quindi viene creata una primitiva RW (ad es. alterando il confine dell'array) e infine gli opcode arbitrari vengono scritti in memoria (ad es. 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: poiché WebKit è così grande, una revisione approfondita del codice è impossibile senza un'enorme quantità di sforzo, quindi è stato impostato il jitter automatico.
Questo deve fare riflettiamo sul fatto che quando abbiamo centomila o milioni di righe di codice, è molto difficile fare in modo che ognuna si comporti bene rispetto alle altre.

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

Ma di regola JavaScript non è mai stato sicuro all'interno del browser. Gli sviluppatori di codice dannoso sono costantemente alla ricerca di modi per sfruttare il funzionamento di ciascun motore e la sua funzionalità JavaScript disponibile per raggiungere obiettivi dannosi.

Nei primi anni, JavaScript era piuttosto pericoloso all'interno del browser. Ora è una corsa costante tra sviluppatori di codice dannoso e sviluppatori di browser / motori e alla fine gli sviluppatori dannosi vincono sempre, anche se solo per un breve periodo. Quindi JavaScript difficilmente può essere definito sicuro. "Dovrebbe essere al sicuro per ora" è un modo più preciso per dirlo.

JavaScript è piuttosto potente

Ecco perché molti utenti lo considerano non sicuro e lo bloccano utilizzando le estensioni del browser. JavaScript consente ai siti Web di tracciare gli utenti in modi non possibili senza di esso, inclusa l'identificazione degli utenti dopo che hanno cancellato i loro cookie mediante l'impronta digitale del browser. Molte delle API web più recenti come WebUSB consentono cose che non sono affatto sicure, ma i browser richiedono l'autorizzazione dell'utente quando accedono ad API non sicure come USB e fotocamera.

Non c'è nulla di intrinsecamente sicuro in JavaScript, per molti versi è meno sicuro di altri linguaggi:

• istruzione eval
• digitazione dinamica

È la sandbox in cui il browser esegue JavaScript che fornisce la sicurezza. Consulta la documentazione sulla sandbox di Chrome qui, nota che non ci sono riferimenti a JavaScript o allo script ECMA.

Oggi, la maggior parte del codice eseguito nel browser è scritta in JavaScript. Con l'ascesa di WebAssembly, probabilmente vedremo la piattaforma del browser passare dal blocco principalmente in una sola lingua di oggi (come un mainframe del passato) a una piattaforma aperta in cui è possibile utilizzare qualsiasi linguaggio conforme a WebAssembly . Questo, in un certo senso, dimostrerà che JavaScript non è particolarmente sicuro / speciale, poiché a quel punto molti linguaggi verranno eseguiti nel browser. Tutte queste lingue utilizzeranno la sandbox fornita dal browser per l'esecuzione.

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

Un programma in codice macchina ha accesso illimitato a qualsiasi interfaccia che il sistema operativo e le librerie forniscono a qualsiasi programma in esecuzione con quell'account utente, è VERAMENTE limitato in ciò che può fare da ciò che l'hardware e il sistema operativo lo limitano a - essenzialmente rendere un tale programma potente quanto l'utente che lo esegue. Potrebbero esserci strumenti che tentano di limitarlo intercettando alcune delle interfacce fornite, ma è difficile impedire a un programma consapevole di tali misure per aggirarle.

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

JavaScript è "relativamente sicuro", ma non "assolutamente sicuro". Qualsiasi codice eseguito sul sistema può potenzialmente causare danni. Non esiste un sistema perfettamente sicuro, tranne quello che non è mai stato utilizzato. JavaScript è più sicuro che inserire un dispositivo USB sconosciuto nel computer e più sicuro di un file binario scaricato da un sito Web ombreggiato o inserito in un allegato di posta elettronica sospetto e molto più sicuro di alcuni degli script che troverai sui siti Web che ti dicono di farlo copia e incolla nella tua shell.

Ha caratteristiche di sicurezza: una sandbox per isolare il processo, un'API relativamente limitata che ha vincoli di sicurezza per evitare di eseguire istruzioni arbitrarie del computer e controlli di sicurezza destinati a limitare l'esposizione di dati sensibili come impronte digitali o condivisione di dati tra domini. Questi sono in cima ai controlli del tuo sistema operativo applicati al binario del browser per limitare comportamenti scorretti e alle applicazioni antivirus che possono aiutare a fermare tali attacchi.

Tuttavia, non è assolutamente sicuro. I bug nel motore di runtime del browser, nel browser stesso, nell'antivirus o persino nel processore stesso possono compromettere la sicurezza di JavaScript. Il sistema è sicuro quanto la sua sicurezza più debole. La sicurezza di JavaScript è pensata principalmente per prevenire exploit "casuali" (come un JavaScript di 8 anni che impara per la prima volta e scrive accidentalmente un exploit), ma non ha alcuna possibilità contro gli aggressori dedicati. JavaScript è talmente complicato che ci possono essere dei bug, forse in modi strani e inaspettati.

Coloro che hanno esperienza in hacking, test penne e sicurezza possono esplorare il codice sorgente, eseguire il debug e fare tutto il possibile per cercare di trovare fessure nell'armatura. I punti deboli dell'implementazione di JavaScript. E JavaScript è abbastanza grande da consentire l'esistenza di tali fessure per cominciare, dal momento che è praticamente impossibile persino automatizzare tutti i possibili test che potrebbero trovare questi bug.

In generale, qualsiasi script tipico in cui potresti imbatterti in un tipico sito web è probabilmente "sicuro", specialmente quelli a cui sono collegati dai principali motori di ricerca. Tuttavia, una volta che inizi a uscire dai sentieri battuti, è incredibilmente probabile che a un certo punto il tuo sistema venga compromesso se c'è anche un singolo punto debole. Ci vuole solo un buon exploit, o talvolta due o tre in tandem, per assumere completamente il controllo di 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 allora, non sarai sicuro al 100%, ma parteciperai attivamente alla tua strategia di mitigazione.

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

JavaScript ha alcune limitazioni come impedire la lettura e la scrittura su disco

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

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

e non consentire l'accesso ad altre finestre o domini del browser.

Se una finestra viene aperta da una finestra già aperta, la comunicazione tra le finestre è possibile utilizzando, tra cui , ma non limitato a, postMessage , MessageChannel , SharedWorker o semplicemente parametri di stringa di query.

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

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

Vedi webkitSpeechRecognition invia l'audio registrato a un telecomando servizio web per impostazione predefinita?

È sicuro perché è stato progettato per essere sicuro. O almeno è sicuro al punto in cui un "JavaScript è piuttosto potente" meno che formale suggerisce che è probabilmente sufficientemente sicuro per rassicurarti. In pratica, nessun software è perfettamente sicuro, quindi è una questione di grado. 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 esaminare i dati di un altro sito (noto come attacco cross-site).

Ovviamente, questo non è perfetto. Recentemente c'è stato uno spavento con Spectre e Meltdown, un paio di exploit che facevano affidamento su un difetto in alcuni processori per liberarsi dal sandbox JavaScript eseguito. Doveva essere patchato con alcuni hack software piuttosto brutti per coprire i processori difettosi.

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

Quindi la vera domanda è: qual è il tuo bar per "sicuro?" Ritieni che Windows sia sicuro? E per Internet Explorer? Adobe Acrobat Reader? OpenJPEG? Il kernel Linux? OpenSSL? La sicurezza e l'usabilità sono sempre in contrasto. Devi usare qualcosa (o forse non lo fai. Gli Amish non sono ancora stati colpiti da 0 giorni ... a meno che non conti un nuovo ceppo di influenza) Per capire davvero se puoi chiamare qualcosa di "sicuro" o non hai bisogno di un modello di minaccia, che definisca come qualcuno potrebbe attaccarti e di un modello di usabilità che definisca quale usabilità devi ottenere mitigando il modello di minaccia. Senza di essi, dobbiamo leggere le tue parole e la tua storia per indovinare cosa significhi "sicuro".