Seguridad de Javascript en los navegadores móviles

7

¿Es Javascript en un navegador móvil más seguro que Javascript en otros tipos de sistemas? Por ejemplo, si tengo un sitio que incluye algún código de cifrado del lado del cliente (Javascript), con la intención de que solo se ejecute dentro de un navegador Safari en el iPhone (independiente o incrustado en una aplicación) o Chrome en un dispositivo Android, ¿qué son algunas posibles vulnerabilidades? ¿Es el cifrado de Javascript del lado del cliente una idea tan terrible en el espacio móvil como el espacio de escritorio?

Advertencias:

  • Hacer una aplicación no es una opción. Esta pregunta es específicamente sobre la seguridad del entorno del navegador móvil. Me doy cuenta de que las API integradas serían una idea mucho mejor.
  • Suponga que el servidor que aloja el código permanece seguro o que la persona está ejecutando el código localmente / fuera de línea.

Esto es lo que he pensado hasta ahora:

  • Secuestro de la transmisión real (solucionable a través de HTTPS, excepto MITM)
  • Mismo origen (solucionable a través de alojamiento en un subdominio dedicado)

Todos los demás ataques (por ejemplo, explotar una falla en el navegador del iPhone) parecen implicar uno de estos dos. Dada la actitud negativa general hacia el cifrado basado en Javascript, debo estar perdiendo algo. ¿Qué me estoy perdiendo?

    
pregunta Devin R 30.04.2013 - 15:16
fuente

1 respuesta

7

Un iPhone con jailbreak o dispositivo Android "rooteado" no se puede distinguir cualitativamente de un sistema de escritorio. Desde el lado del servidor, no puede saber si el dispositivo está rooteado o no; O incluso si realmente es el dispositivo, usted cree que debe ser. Cualquier problema que pueda tener el cifrado basado en Javascript en los sistemas de "escritorio" también se aplica a las plataformas móviles. Por supuesto, cualquier navegador individual (no plataforma) puede tener características más o menos problemáticas al respecto, pero los navegadores son bastante uniformes en todas las plataformas (Safari en iOS comparte una gran cantidad de código con Safari en MacOS X o Windows, por ejemplo).

Esto no significa que la criptografía de Javascript esté condenada; solo que tiene que trabajar dentro de las restricciones de ese idioma y su entorno (el navegador), que son algo adversos a las tareas para las que se considera necesaria la criptografía. En particular:

  • El código Javascript se ejecuta en el cliente y no se puede proteger de los ojos curiosos del usuario, si tiene la intención de realizar ingeniería inversa ( ofuscación de código solo puede llevarte hasta ahora, es decir, no muy lejos). Si integras secretos en el código Javascript, tu única protección real es la oración.

  • Javascript tiene muy poco acceso a las instalaciones de la plataforma, en particular al espacio de almacenamiento.

  • Dado que el código Javascript no se almacena localmente (se puede almacenar en caché pero la duración del almacenamiento en caché no se puede aplicar de manera confiable desde el servidor), se debe redistribuir nuevamente desde el servidor. Dado que los datos desprotegidos enviados a través de Internet pueden alterarse, esta distribución debe pasar por algunos HTTPS, y confía de forma inherente en el servidor para que no juegue juegos de foul. La presencia de HTTPS y la confianza en el servidor eliminan la mayoría de las razones por las que la criptografía debe realizarse en el lado del cliente.

    (Si no confías en el servidor, entonces no puedes usar lógicamente el código Javascript enviado por ese servidor. El problema de confiar en el servidor es real, pero Javascript no es la solución para ello).

  • Para tareas de cómputo masivas (por ejemplo, criptografía), el rendimiento de Javascript es un gran éxito.

No hay nada en los dispositivos móviles que modifique significativamente estas restricciones, en comparación con la situación en los sistemas de escritorio.

    
respondido por el Tom Leek 30.04.2013 - 20:23
fuente

Lea otras preguntas en las etiquetas