2012-01-12 7 views
5

Beh, non è un grosso rischio per la sicurezza, anche se rivela almeno alcune potenziali interferenze.Non è JavaScript setTimeout e setInterval hanno qualche potenziale vulnerabilità di sicurezza

Supponiamo di avere quei moduli JavaScript molto ben chiusi che vengono caricati nella mia pagina senza conoscersi l'un l'altro. Sono da "fidati", tuttavia alcuni sviluppatori di lib2 hanno fatto un errore, vedere il codice.

Lib1http://good.site/libs/the-famous-important-lib1.js

setInterval(function(){ 
    alert('I am doing some important stuff'); 
}, 1000); 

LIB2http://not-excelent.site/libs/the-cool-lib2.js

var i = setInterval(function(){}, 0); 
for(; i >= 0; i-=1) { 
    clearInterval(i); 
} 

My Html

<script src="http://good.site/libs/the-famous-important-lib1.js" type="text/javascript"></script> 
<script src="http://not-excelent.site/libs/the-cool-lib2.js" type="text/javascript"></script> 

In un browser o almeno su Firefox, il caricamento di Lib2 causerebbe la totale interruzione di Lib1. Qualcuno potrebbe dire che questo non è importante, e che sciocco fare questo errore.

Lo considero un cattivo comportamento. Dal momento che stiamo caricando sempre più librerie di terze parti nei nostri siti web. Forse una soluzione adeguata è che setInterval e setTimeout dovrebbero restituire un Ojbect per essere davvero unico e non-falso, invece che solo un numero di incremento automatico numerico.

Qualcuno potrebbe sfruttare uno sfruttamento del mondo reale per questo (ancora non ha testato se si tratta di frame incrociati, ne dubito davvero).

La domanda è: E '? e la modalità rigorosa in es5 lo supera?

+0

cancellare gli altri setIntervals? Certo che spezzerà le cose, ma non può accadere nulla di catastrofico. –

+0

soluzione facile .. non utilizzare il codice di altri rifiuti della gente;) – musefan

+3

@SergioTulentsev Ho tuttavia visto un sito Web il cui paywall è _triggered_ da un 'setTimeout()'. Se il timer viene cancellato, i clienti non paganti non vengono espulsi. Assolutamente _lousy_ security design ... – Alnitak

risposta

3

La modalità rigorosa in es5 lo supera?

No. setInterval e setTimeout fanno parte le associazioni DOM - non sono i comandi incorporati ECMAScript, quindi non sono specificate in qualsiasi versione di EcmaScript. Niente in modalità rigorosa influisce in modo specifico su di loro.

Questo probabilmente cambierà nella prossima versione della EcmaScript dal comitato TC39 pensa che la concorrenza è una caratteristica del linguaggio di base che deve essere specificato e sarà probabilmente mantenere event loop concurrency.

È improbabile che tali modifiche influiscano sul problema che si pone.Caja/Secure EcmaScript (SES) si assicura che gli id ​​di intervallo e di timeout non siano ipotizzabili.

3

Punto interessante.

Dal ids intervallo/timeout sono sequenziali, è possibile (come ci hai mostrato) Cancellare tutti gli intervalli/timeout da ottenersi successivo intervallo id, e che cercare di cancellare qualsiasi ids inferiore a quello che hai.

Tuttavia, non vedo alcuna minaccia sicurezza lì. Qualsiasi applicazione web, che baserebbe la propria sicurezza esclusivamente su intervallo e/o timeout in Javascript, è altrettanto buona quanto compromessa.

Come già commentato da Sergio Tulentsev: abusare di clearInterval/clearTimeout spezzerà le cose - di sicuro - ma (il 99% delle volte) che non porrà alcuna minaccia alla sicurezza per l'applicazione web.

+1

Stavo parlando di sicurezza e sicurezza linguistica non solo della sicurezza delle applicazioni, poiché quando passiamo molto tempo a nascondere i nostri moduli all'interno delle chiusure (che è buona), e abbiamo invitato la "modalità rigorosa". JavaScript dovrebbe evitare questi sciocchi punti di rottura, anche se so che è complicato da raggiungere poiché è JavaScript e ci sono molte persone coinvolte. –

Problemi correlati