Come posso limitare o limitare i file Javascript (* .js) di terze parti in grado di DOS il mio sito?

3

Molti proprietari di siti web integrano Google analytics, vari social media javascript o plug-in di Facebook o Twitter nelle loro pagine web. Il problema è che questa fiducia sembra essere "tutto o niente", il che significa che non ci sono limiti o struttura riguardo a ciò che il sito di terze parti è autorizzato a fare.

Inoltre, non sembra esserci alcuna gestione di eccezioni strutturate (SEH) disponibile per Javascript ogni volta che gli script dell'autore del sito web indipendente risiedono nella stessa pagina Web.

Esempio

On 2/7 / 13 diversi siti che si integrano con Facebook hanno efficacemente dosato metà di Internet, rendendo inutilizzabili diversi siti. Penso che questo problema potrebbe essere evitato se il javascript di terze parti potrebbe essere limitato (come definito dal proprietario del sito web e onorato dal browser), e / o ci fosse una variazione di gestione delle eccezioni meta-strutturata per Javascript.

Domanda

  • Esiste qualche ricerca o proposta che tenta di limitare o controllare il javascript di terze parti a qualsiasi livello?

  • Quale gruppo di lavoro (gruppo W3C, RFC, fornitore, ecc.) è il più appropriato per proporre formalmente e definire uno standard per i controlli javascript di terze parti?

posta random65537 08.02.2013 - 02:40
fonte

4 risposte

3

No. In pratica, non esiste una buona soluzione a questo problema. Se includi una libreria Javascript di terze parti nella tua pagina web (tramite <SCRIPT SRC=...> ), ti stai fidando di Javascript. Ciò include fidarsi di non farlo. È proprio come funziona, e non c'è soluzione, visto l'attuale modello di sicurezza del browser.

Se non ti fidi dei Javascript di terze parti, non incorporarli nella tua pagina web. Questa è l'unica soluzione ragionevole oggi.

(In linea di principio potresti usare Caja, ma è un meccanismo piuttosto complesso: è un po 'come usare un cannone per sparare al volo.)

    
risposta data 08.02.2013 - 22:51
fonte
2

In primo luogo, questo sembra derivare da un errore di qualcuno su Facebook che ha accesso ad aggiornare i propri script JS al proprio CDN che non è stato notato / risolto da qualcuno su Facebook per 15-20 minuti. Dubito che sia stato un attacco malevolo (in quanto è stato reindirizzato solo a una pagina di errore e si applicava solo alle persone attualmente loggate su Facebook piuttosto che a tutti).

Quindi soluzioni come La politica di sicurezza dei contenuti non è pertinente in quanto i vari siti Web hanno deliberatamente deciso di includere il javascript di Facebook-Connect nella loro pagina e di volere che venga eseguito. La politica di sicurezza dei contenuti limita semplicemente a quali domini è consentito eseguire codice per mitigare XSS.

Allo stesso modo, dubito che Facebook adotterà ADSafe di Douglas Crockford (o eseguirà il proprio codice tramite google-caja), e anche se lo facessero o scrivessero il proprio codice, probabilmente lo pubblicherebbero entrambi dal loro CDN. Quindi dovresti comunque fidarti fondamentalmente di Facebook per la competenza tecnica.

La soluzione migliore è esitare prima di consentire a terze parti di caricare il codice sulla tua pagina. Hai davvero bisogno di un pulsante Facebook Like / Share attivo su ogni pagina? Potresti semplicemente includere un collegamento statico come la tua organizzazione su Facebook e aspettarti che le persone condividano i contenuti copiando l'URL nel loro feed di Facebook?

Magari prendi una versione statica dei loro file javascript che funziona correttamente; anche se questo potrebbe essere problematico se (a) smettono di supportare vecchie versioni dei loro file JS o (b) hanno un controllo (possibilmente attraverso CSP) che lo script è stato servito dal loro CDN (anche se non credo che CSP possa farlo al momento) o (c) la versione statica che hai tirato aveva un codice fastidioso che non ti piaceva.

La mia ipotesi è che Facebook considererà questo errore seriamente e probabilmente non accadrà presto da loro. Dovrebbero fare cose come richiedere che i loro script siano serviti solo tramite https, e sottoporsi a test di qualità automatici e manuali significativi prima della distribuzione - ad esempio, nessun codice diventa attivo se non ha passato giorni di test (le correzioni dei bug non dovrebbero essere implementate live ma ripristina l'ultima versione funzionante).

    
risposta data 08.02.2013 - 17:14
fonte
1

Forse questo può aiutarti.

link - ADsafe rende sicuro inserire codice ospite (ad esempio pubblicità o widget di script di terze parti) su una pagina web. ADsafe definisce un sottoinsieme di JavaScript abbastanza potente da consentire al codice guest di eseguire interazioni di valore, evitando allo stesso tempo danni o intrusioni dannosi o accidentali.

link - Compilatore per rendere HTML, CSS e JavaScript di terze parti sicuri per l'incorporamento

  • Sembra molto buono, ma il codice di terze parti deve essere inviato a un server Caja (Google fornisce anche uno) per "compilare".
risposta data 08.02.2013 - 09:26
fonte
1

Non sono sicuro di aver capito correttamente la tua domanda, ma esiste già un sistema che controlla da quali domini JavaScript sarà accettato.

Se sei il proprietario di un sito web, puoi aggiungere Content-Security-Policy (CSP) per l'intestazione delle tue pagine. Nel CSP è possibile definire i domini, da cui una pagina accetta JavaScript. Se il browser degli utenti supporta il CSP (Firefox dalla versione 4), JavaScript non verrà caricato da altri domini definiti. Quindi le librerie JavaScript da google.com non potevano caricare altre librerie da example.com .

Ci sono molte altre opzioni in CSP, dipende dal browser se sono rispettate o meno.

    
risposta data 08.02.2013 - 13:14
fonte