html5 - html title attribute

¿El almacenamiento local se puede considerar seguro?

Question

Estoy obligado a desarrollar una aplicación web que funcionará fuera de línea durante largos períodos. Para que esto sea viable, no puedo evitar guardar datos confidenciales (datos personales, pero no el tipo de datos que almacenaría solo hash) en el almacenamiento local.

Acepto que esto no es una práctica recomendada, pero con pocas opciones estoy haciendo lo siguiente para asegurar los datos:

• encriptar todo lo que entra en el almacenamiento local utilizando la biblioteca stanford javascript crypto y AES-256
• la contraseña de usuario es la clave de cifrado y no está almacenada en el dispositivo
• sirviendo todo el contenido (cuando está en línea) desde un solo servidor confiable a través de ssl
• validación de todos los datos que van desde y hacia el almacenamiento local en el servidor utilizando el proyecto owasp antisamy
• en la sección de red de la aplicación, sin utilizar *, y en su lugar enumerar solo los URI necesarios para la conexión con el servidor de confianza
• en general, tratando de aplicar las pautas sugeridas en la hoja de trucos de OWASP XSS

Aprecio que el diablo a menudo esté en los detalles, y sepa que hay mucho escepticismo sobre el almacenamiento local y la seguridad basada en JavaScript en general. ¿Alguien puede comentar si hay:

• defectos fundamentales en el enfoque anterior?
• cualquier posible solución para tales defectos?
• ¿Hay alguna forma mejor de proteger el almacenamiento local cuando una aplicación html 5 debe funcionar sin conexión durante largos períodos de tiempo?

Gracias por cualquier ayuda.

Answer 1

Bueno, la premisa básica aquí es: no, aún no es seguro.

Básicamente, no puede ejecutar crypto en JavaScript: Criptografía de JavaScript considerada nociva .

El problema es que no puede obtener de manera confiable el código criptográfico en el navegador, e incluso si pudiera, JS no está diseñado para que pueda ejecutarlo de manera segura. Por lo tanto, hasta que los navegadores tengan un contenedor criptográfico (que las Extensiones de Medios Encriptados proporcionan, pero se están reuniendo para sus propósitos de DRM), no será posible hacerlo de forma segura.

En cuanto a una "Mejor manera", no hay una ahora. Su única alternativa es almacenar los datos en texto sin formato y esperar lo mejor. O no almacene la información en absoluto. De cualquier manera.

O eso, o si necesita ese tipo de seguridad y necesita almacenamiento local, cree una aplicación personalizada ...

Answer 2

Como una exploración de este tema, tengo una presentación titulada "Asegurando TodoMVC usando la API de criptografía web" ( video , code ).

Utiliza la API de Web Cryptography para almacenar la lista de tareas pendientes cifrada en localStorage mediante la protección con contraseña de la aplicación y el uso de una clave derivada de contraseña para el cifrado. Si olvida o pierde la contraseña, no hay recuperación. ( Descargo de responsabilidad: era un POC y no estaba destinado para uso en producción ) .

Como dicen las otras respuestas, esto todavía es susceptible de instalar XSS o malware en la computadora cliente. Sin embargo, cualquier dato sensible también estaría en la memoria cuando los datos estén almacenados en el servidor y la aplicación esté en uso. Sugiero que el soporte fuera de línea puede ser el caso de uso convincente.

Al final, el encriptado localStorage probablemente solo proteja los datos de los atacantes que tienen acceso de solo lectura al sistema o sus copias de seguridad. Agrega una pequeña cantidad de defensa en profundidad para OWASP Top 10 item A6-Sensitive Data Exposure , y le permite responder "¿Alguno de estos datos está almacenado en texto claro a largo plazo?" correctamente.

Answer 3

Este es un artículo realmente interesante aquí. Estoy considerando implementar el cifrado JS para ofrecer seguridad al usar el almacenamiento local. Está absolutamente claro que esto solo ofrecerá protección si el dispositivo es robado (y se implementa correctamente). No ofrecerá protección contra keyloggers, etc. Sin embargo, este no es un problema de JS ya que la amenaza de keylogger es un problema de todas las aplicaciones, independientemente de su plataforma de ejecución (navegador, nativo). En cuanto al artículo "JavaScript Crypto Considered Harmful" al que se hace referencia en la primera respuesta, tengo una crítica; indica "Se puede usar SSL / TLS para resolver este problema, pero eso es caro y complicado". Creo que este es un reclamo muy ambicioso (y posiblemente bastante parcial). Sí, SSL tiene un costo, pero si nos fijamos en el costo de desarrollar aplicaciones nativas para múltiples sistemas operativos, en lugar de hacerlo en la web debido a este problema, el costo de SSL se vuelve insignificante.

Mi conclusión: hay un lugar para el código de cifrado del lado del cliente, sin embargo, como con todas las aplicaciones, los desarrolladores deben reconocer sus limitaciones e implementarlas si es adecuado para sus necesidades, y garantizar que haya formas de mitigar sus riesgos.

Answer 4

No se puede acceder a ninguna página web (verdadera) pero es fácilmente accesible y fácilmente editable a través de herramientas de desarrollo, como chrome (ctl-shift-J). Por lo tanto, se requiere criptografía personalizada antes de almacenar el valor.

Pero, si JavaScript necesita descifrar (validar), entonces el algoritmo de descifrado queda expuesto y puede ser manipulado.

Javascript necesita un contenedor totalmente seguro y la capacidad de implementar correctamente variables privadas y funciones que están disponibles solo para el intérprete js. Pero esto viola la seguridad del usuario, ya que los datos de seguimiento se pueden usar con impunidad.

En consecuencia, javascript nunca será completamente seguro.

Answer 5

No.

Se puede acceder a localStorage desde cualquier página web, y si tiene la clave, puede cambiar los datos que desee.

Dicho esto, si puede idear una forma de cifrar las claves de forma segura, no importa cómo transfiere los datos, si puede contener los datos dentro de un cierre, entonces los datos son (algo) seguros.

Answer 6

Supongo que la principal preocupación es que alguien tenga acceso físico a la computadora y lea localStorage para su sitio, y quiere que la criptografía lo ayude a evitar ese acceso.

Si alguien tiene acceso físico también estás abierto a ataques diferentes y peores que la lectura. Estos incluyen (pero no están limitados a): keyloggers, modificación de script fuera de línea, inyección local de scripts, envenenamiento de la memoria caché del navegador y redireccionamientos de DNS. Esos ataques solo funcionan si el usuario usa la máquina después de haber sido comprometida. Sin embargo, el acceso físico en dicho escenario significa que tienes problemas mayores.

Por lo tanto, tenga en cuenta que el escenario limitado donde el cifrado local es valioso sería si la máquina es robada.

Hay bibliotecas que implementan la funcionalidad deseada, por ejemplo, Stanford JavaScript Crypto Library . Sin embargo, hay debilidades inherentes (como se menciona en el enlace de la respuesta de @ ircmaxell):

1. La falta de entropía / generación de números aleatorios;
2. La falta de un almacén de claves seguro, es decir, la clave privada debe estar protegida con contraseña si se almacena localmente o almacenada en el servidor (lo que bloquea el acceso fuera de línea);
3. La falta de borrado seguro;
4. La falta de características de sincronización.

Cada una de estas debilidades se corresponde con una categoría de compromiso criptográfico. En otras palabras, aunque pueda tener "criptografía" por nombre, estará muy por debajo del rigor al que se aspira en la práctica.

Es probable que estas preocupaciones se aborden en la API WebCrypto , pero eso aún no está aquí.

Dicho todo esto, la evaluación actuarial no es tan trivial como "JavaScript crypto es débil, no lo use". Esto no es un endoso, estrictamente una advertencia y requiere que comprenda completamente la exposición de las debilidades anteriores, la frecuencia y el costo de los vectores que enfrenta, y su capacidad de mitigación o seguro en caso de falla: Javascript crypto, en a pesar de sus debilidades, puede reducir su exposición, pero solo contra ladrones con capacidad técnica limitada. Sin embargo, debe suponer que JavaScript crypto no tiene ningún valor contra un atacante determinado y capaz que está apuntando a esa información. Algunos considerarían engañoso llamar a los datos "encriptados" cuando se sabe que muchas debilidades son inherentes a la implementación. En otras palabras, puede disminuir marginalmente su exposición técnica pero aumenta su exposición financiera a partir de la divulgación. Cada situación es diferente, por supuesto, y el análisis de la reducción de la exposición técnica a la exposición financiera no es trivial. Aquí hay una analogía ilustrativa: algunos bancos requieren contraseñas débiles , a pesar del riesgo inherente, porque su exposición a pérdidas por contraseñas débiles es menor que los costos del usuario final de respaldar contraseñas seguras.

🔥 Si leíste el último párrafo y pensaste "Un tipo en Internet llamado Brian dice que puedo usar Javascript crypto", no uses Javascript crypto.

Para el caso de uso descrito en la pregunta, parece tener más sentido para los usuarios cifrar su partición local o directorio particular y usar una contraseña segura. Ese tipo de seguridad generalmente es bien probado, ampliamente confiable y comúnmente disponible.