In cima alla mia testa, posso pensare a quattro modi in cui questa strategia potrebbe fallire. Tutto può essere mitigato in una certa misura attraverso pratiche di sviluppo e buon senso da parte degli utenti, e alcuni richiederebbero alcuni attacchi molto mirati, ma sono comunque rischi.
Numeri
La memorizzazione di dati riservati nell'heap sarà rischiosa se si intende utilizzare eval , poiché il codice in esecuzione in eval può accedere alle variabili nell'ambito della chiamata eval, che potrebbe includere le variabili heap. Prendere in considerazione:
var creditCardNumber = 123456789;
var evalString = "window.alert(creditCardNumber)";
eval(evalString); // alerts the credit card number!
Ci sono un paio di modi in cui un utente malintenzionato potrebbe montare un attacco:
- Se evalString viene pescato da un database, un utente malintenzionato potrebbe tentare di influenzare tali dati in qualche modo
- Se la tua applicazione utilizza un codice di terze parti, un utente malintenzionato potrebbe provare a dirottare tale risorsa e utilizzare
eval per afferrare i dati e inviarli in avanti (ricorda: il codice eseguito da diversi script continuerà a condividere l'heap stesso). Questo rischio potrebbe essere mitigato se i dati riservati sono in qualche modo trattenuti in una chiusura anziché esposti direttamente sull'heap, ma tali pratiche sarebbero facili da interrompere per uno sviluppatore ingenuo.
Ricorda che chiamare window.setTimeout e window.setInterval con argomenti stringa sono alias anche per eval .
Estensioni browser
Le estensioni del browser possono avere l'opportunità di ispezionare il contenuto dell'heap di JavaScript, direttamente o indirettamente. Ad esempio, Chrome fornisce un'API di debug per estensioni create come strumenti per sviluppatori. Gli utenti devono tuttavia concedere le autorizzazioni per utilizzare queste estensioni e installarle di proposito, quindi questo potrebbe non essere un modo semplice per montare un attacco.
Reverse engineering
Anche il codice minificato può ancora essere decodificato, quindi è sempre possibile per gli utenti malintenzionati ragionare su come si sta eseguendo la crittografia e il modo in cui l'applicazione JavaScript si scontra con il server.
Esposizione accidentale tramite codice di terze parti
Potresti essere sicuro che il tuo codice non assegna mai creditCardNumber a qualcosa di persistente come localStorage o lo serializza a JSON e lo spinge a window.name , ma sei altrettanto sicuro del codice di terze parti? Potrebbe valerne la pena controllare se stai passando l'oggetto, in particolare se lo stai passando a qualcosa che tenta di eseguire il caching.