Desde lo alto de mi cabeza, puedo pensar en cuatro formas en que esta estrategia podría fallar. Todo puede ser mitigado en cierta medida a través de prácticas de desarrollo sensatas y sentido común por parte de los usuarios, y algunos requerirían algunos ataques muy específicos, pero sin embargo son riesgos.
Eval
El almacenamiento de datos confidenciales en el montón será arriesgado si pretende usar eval , porque el código que se ejecuta en eval puede acceder a las variables en el alcance de la llamada a evaluación, que pueden incluir las variables del montón. Considera:
var creditCardNumber = 123456789;
var evalString = "window.alert(creditCardNumber)";
eval(evalString); // alerts the credit card number!
Hay varias formas en que un usuario malintencionado podría montar un ataque:
- Si evalString se extrae de una base de datos, un atacante podría intentar influir en los datos de alguna manera
- Si su aplicación usa código de terceros, un atacante podría intentar secuestrar ese recurso y usar
eval para capturar los datos y enviarlos hacia adelante (recuerde: el código que se ejecuta desde diferentes scripts seguirá compartiendo el mismo montón). Este riesgo podría mitigarse si los datos confidenciales se mantienen de algún modo en un cierre en lugar de exponerse directamente en el montón, pero tales prácticas serían fáciles de romper para un desarrollador ingenuo.
Recuerde que llamar a window.setTimeout y window.setInterval con argumentos de cadena también son alias para eval .
Extensiones de navegador
Las extensiones del navegador pueden tener la oportunidad de inspeccionar el contenido del montón de JavaScript, directa o indirectamente. Por ejemplo, Chrome proporciona una API de depuración para extensiones creadas como herramientas de desarrollo. Sin embargo, los usuarios deben otorgar permisos para usar estas extensiones e instalarlas a propósito, por lo que esta podría no ser una forma sencilla de montar un ataque.
Ingeniería inversa
Incluso el código minificado aún puede diseñarse a la inversa, por lo que siempre es posible que los usuarios malintencionados razonen acerca de cómo está realizando el cifrado y la forma en que su aplicación de JavaScript se da en el servidor.
Exposición accidental a través del código de terceros
Puede estar seguro de que su código nunca asigna creditCardNumber a algo persistente como localStorage o lo serializa a JSON y lo empuja a window.name , pero ¿tiene la misma confianza en el código de terceros? Podría valer la pena comprobar si está pasando el objeto, especialmente si lo está pasando a algo que intenta realizar el almacenamiento en caché.