Qual è il pericolo di avere un codice casuale, fuori controllo, in esecuzione sulle mie pagine?

Rischio

Nello scenario peggiore, potrebbe rendere il sito Web completamente inaccessibile per gli utenti, potrebbe eseguire determinate azioni come ad esempio (richiedendo la rimozione dell'account, spendendo denaro) o potrebbe rubare dati riservati.

Prevenzione

Non può essere fatto. Se esegui JavaScript di qualcun altro sul tuo sito web, diventa non più sicuro di quello di terze parti. Devi ospitarlo da solo.

Puoi comunque avvicinarti al bersaglio.

1. Una cosa potrebbe essere Politica di sicurezza dei contenuti . L'impostazione di esempio dell'intestazione Content-Security-Policy su script-src 'self' www.google-analytics.com; , impedirebbe l'esecuzione di script offerti da domini diversi dal tuo o www.google-analytics.com . In questo modo, se qualcuno trovasse qualche vulnerabilità di scripting cross-site (XSS) che consentirebbe loro di aggiungere il proprio codice JavaScript incorporato al tuo sito Web, non verrebbe eseguito.
2. Un'altra cosa davvero interessante è la cosiddetta Integrità della subunità . È essenzialmente l'aggiunta della somma hash di JS che ti aspetti di eseguire sul parametro integrity che assegni al tag script .

<script src="https://example.com/example-framework.js"integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"/>

Puoi generare questi hash online al link o con il comando:

openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A 

Questo ovviamente ha aspetti negativi, ad es. i fornitori di analisi possono cambiare i loro script e dovrai modificare il parametro integrity per mantenerli in esecuzione. È anche una funzionalità piuttosto nuova (Chrome 45.0+, Firefox 43+, Opera 32+, nessun supporto IE, Edge o Safari al momento), quindi si pone la sicurezza del client sul proprio software.

Vedi anche Cheat Sheet di gestione Javascript di terze parti di OWASP.

What's the worst thing that can happen?

La terza parte può fare qualsiasi cosa tu possa fare con JavaScript - o qualsiasi cosa un hacker possa fare con XSS.

Ciò include il furto di cookie, l'iniezione di un keylogger JavaScript, l'esclusione della protezione CSRF e l'esecuzione di qualsiasi richiesta che potresti eseguire, ad esempio l'aggiunta di un nuovo utente amministratore, o la modifica del contenuto della tua pagina web (ad esempio per iniettare annunci o per attacchi di phishing) .

How do I get started with dealing with the risk?

Se non ti fidi delle intenzioni o della sicurezza della terza parte, l'unica soluzione appropriata sarebbe quella di ospitare lo script da solo (dopo esserti assicurato che faccia solo ciò che vuoi che faccia).

Se non vuoi farlo, potresti aggiungere l'Integrità della subunità per mitigare un po 'il rischio:

Aggiungi un hash dello script all'inserimento e browser moderni confronterai l'hash con l'hash del file incluso. Se non corrisponde, il codice non verrà eseguito: <script src="https://example.com/script.js"integrity="[hash]" crossorigin="anonymous"></script> . In questo modo, puoi assicurarti che lo script non cambierà. Ovviamente, se cambia, è necessario ricontrollare lo script e modificare l'hash, altrimenti il sito Web verrà interrotto.

What risks are raised by this uncontrolled code? What's the worst thing that can happen?

Generalmente, l'attaccante ottiene l'accesso a qualsiasi cosa i tuoi metodi di autenticazione siano destinati a proteggere.

Nel peggiore dei casi, supponiamo che il codice sia stato progettato appositamente per il tuo sito. Le azioni eseguite dall'utente possono essere richieste per immettere le credenziali di sicurezza, consentendo all'utente malintenzionato di accedere all'account dell'utente per molto tempo dopo il logout. Per un conto bancario, un portafoglio bitcoin o altri siti che controllano l'accesso alle risorse, l'utente malintenzionato avrà accesso a azioni irreversibili ad alto valore. Se al momento non c'è un valore ma ottengono le credenziali per accedere all'account, possono aspettare fino a quando non c'è abbastanza valore nell'account per renderlo utile.

How do I get started with dealing with the risk?

Buono: imposta la politica di sicurezza del contenuto e l'integrità della sotto-risorsa sugli script che ospiti. Vedi la risposta di @ Przemek per ulteriori informazioni su quelli. Non sono sicuro che sia necessario dirlo, ma tutti i JavaScript devono essere pubblicati su HTTP; questo almeno aumenta il costo del MITM per quelle risorse.

Migliore: ospita il codice tu stesso. Ma, non dimenticare di aggiornarlo regolarmente. Questi venditori rilasciano proprie correzioni di sicurezza. Non lasciarti indietro.

Migliore: rivedere tutto il codice sorgente. Nella maggior parte dei casi è possibile trovare versioni non ridimensionate del JS che è possibile leggere (e alla fine solo diff), quindi ridimensionarle e raggrupparle con il resto dei siti JS. Ovviamente questo è un costo elevato, lo appesantisce in modo appropriato rispetto alle esigenze del tuo sito.

What's the worst thing that can happen?

Il termine tecnico è esecuzione di codice arbitrario . In questo contesto, "arbitrario" significa "qualsiasi", come in "tutto ciò che è possibile codificare in JavaScript potrebbe finire in esecuzione sul tuo sito".

È possibile utilizzare JavaScript per leggere i valori dai campi del modulo? Sì. È possibile utilizzare JavaScript per caricare qualcosa da un URL? Sì. Quindi l'esecuzione di codice arbitrario significa che qualcuno potrebbe leggere il nome utente e la password di un utente mentre si collegano e trasmetterli al proprio server, codificati come parametri in una richiesta GET. (Ciò fornisce un accurato controllo della crittografia HTTPS dei dati di accesso dei tuoi utenti, BTW.)

È possibile utilizzare JavaScript per leggere i dati su una pagina? Sì. Quindi l'esecuzione di codice arbitrario significa che qualcuno potrebbe leggere i dati del profilo privato di un utente quando accedono alla pagina che lo contiene. (E usa una richiesta HTTP per segnalarlo al server dell'attaccante.)

... e così via. Una vulnerabilità arbitraria nell'esecuzione di codice è considerata la cosa peggiore possibile dal punto di vista della sicurezza informatica, perché sfruttarla significa che letteralmente qualsiasi cosa negativa possibile può essere eseguita sul tuo sistema.

Tutto questo vale la pena di considerare, ma per essere onesti, ci sono pratiche di sviluppo ben accettate e protezioni integrate nei browser moderni che proteggono dai casi più gravi rilevati.

Vale anche la pena notare che ci sono tre modi in cui il codice di terze parti può essere eseguito nel contesto (ovvero, condividendo lo stesso DOM del browser) delle tue pagine web: 1) JS che includi e esegui il rendering insieme alla tua pagina, per esempio Google Analytics o 2) Bookmarklets che l'utente controlla (ad esempio Spritzlet o Pinterest) e 3) estensioni o barre degli strumenti del browser. Questi ultimi due sono quasi completamente fuori dal tuo controllo; il primo è qualcosa che puoi controllare in una certa misura.

Di gran lunga la cosa più importante da garantire è che i server web che controlli e che rispondono al client (browser, bot, malware) sono bloccati. XSS, CSRF, SQL Injection e molti altri vettori di attacco sono sotto il tuo controllo sul lato server. Dovresti esplicitamente consentire CORS sul tuo server, ma se lo fai, assicurati di sapere cosa stai facendo e sii particolarmente vigile. Questo non vuol dire che questa roba sia tutto facile o ovvio o altro, ma è del tutto indipendente dal fatto che la vulnerabilità venga violato tramite JS o qualsiasi altro metodo.

Supponendo di aver protetto il tuo server web e bloccato gli endpoint che possono essere chiamati, il resto di ciò che va storto rientra in una classe diversa. JS (e plugin / estensioni / barre degli strumenti / bookmarklets) può fare una vasta gamma di cose cattive: i logger di battitura, l'iniezione di elementi dall'aspetto innocuo che in realtà inviano dati altrove, e così via. Tutti questi sono eseguiti dal browser.

Se stai servendo il JS per conto di terzi, devi fare attenzione a fidarti e verificare la fonte. Uno snippet di Google Analytics è probabilmente sicuro. Un widget di pubblicazione di annunci di terze parti potrebbe valere la pena di esaminare più attentamente. In tutti i casi, è possibile ispezionare il codice sottostante: se il browser può eseguirlo, è possibile vedere il codice JS e decidere: è questo qualcosa che si desidera sul tuo sito?

JavaScript è uno strumento potente. Ma alla fine, JS è un software che il browser esegue e quindi confidiamo molto nei browser e nei sistemi operativi che li eseguono per garantire la sicurezza. JS non è un software che ha particolari abilità magiche per violare il tuo server o fare fare al tuo server cose che non è stato progettato per fare.

Non c'è poco o nulla che il tuo sito possa fare che permetta a JS di eseguire arbitrariamente codice su un computer dell'utente - è l'utente che deve avere aggiornamenti recenti a browser e sistema operativo, ecc. Puoi rilevare vecchie versioni e postare avvisi sii un bravo ragazzo, ma questo è tutto.

Proteggi il tuo server, installa gli aggiornamenti, assicurati che il tuo codice sia sicuro, evita di servire JS da terze parti sconosciute. Quindi, assicurati che il tuo sito sia registrato con Strumenti per i Webmaster di Google che ti informerà se il tuo sito è compromesso in molti casi e, se te lo puoi permettere, ottieni un servizio che analizza il tuo sito per individuare eventuali vulnerabilità.