No. Las cajas de arena no están sobrevaloradas. Son muy útiles. No son una bala de plata, no resuelven todos los problemas de seguridad, pero tienen un valor sustancial.

Realmente, no creas que esto es especialmente nuevo. Si lees el documento original que describe la arquitectura de seguridad de Chrome, explica claramente por qué el sandboxing es valioso al tiempo que explica sus limitaciones. Por ejemplo, la introducción dice:

  

La arquitectura de Chromium está diseñada para mitigar las vulnerabilidades más graves, es decir, aquellas vulnerabilidades que permiten a un atacante ejecutar   código arbitrario [...] Encontramos que 38 de las 87 vulnerabilidades del motor de renderización permitieron que un atacante ejecutara código arbitrario y tendría   Ha sido mitigado por la arquitectura de cromo. Estas cuentas   para el 70,4% (38 de 54) de todas las vulnerabilidades divulgadas que permiten   Ejecución de código arbitrario.

Por lo tanto, la arquitectura de Chrome hace una gran contribución para mitigar las vulnerabilidades más graves que uno puede tener en un navegador.

Al mismo tiempo, el equipo de Chrome nunca afirmó que el sandboxing es una bala de plata. Por ejemplo, consulte "Objetivos fuera de alcance" en ese documento para obtener una descripción clara de algunas vulnerabilidades que la arquitectura de la zona de pruebas de Chrome no intenta mitigar. Cualquiera que haya estado siguiendo esto ya debería estar consciente del hecho de que el sandboxing no pretende detener todos los problemas de seguridad.

Lea el documento aquí:

• La arquitectura de seguridad del navegador Chromium , Adam Barth, Collin Jackson, Charles Reis y El equipo de Google Chrome.

Recuerde, las vulnerabilidades que permiten que un atacante ejecute un código malicioso en su sistema local (también conocido como descargas ocultas) son el tipo de vulnerabilidad más grave. Un atacante que explota dicha vulnerabilidad también puede atacar todos sus datos "en la nube" o en los servidores. Lo opuesto no es verdad. En consecuencia, las descargas drive-by son el tipo de vulnerabilidad más grave que se puede tener en un navegador web.

Si nos fijamos hace unos años, estas vulnerabilidades "drive-by-download" en los navegadores eran muy comunes. Dada su gravedad y prevalencia, es natural que los investigadores y los profesionales de la seguridad gasten mucha energía buscando formas de mitigar o eliminar ese tipo de vulnerabilidades. La comunidad de seguridad ha encontrado formas razonables de reducir significativamente la prevalencia de dichas vulnerabilidades.

Entonces, claro, una vez que logre un buen progreso en la eliminación de las vulnerabilidades más comunes y graves, es natural que empiece a ver cómo abordar los siguientes problemas más graves. Pero eso no significa que el sandboxing esté "sobrevalorado". Y, eso no significa que la energía puesta en derrotar las descargas de drive-by fue desperdiciada o extraviada. No fue Fue importante, y sigue siendo importante hoy.

Esta es una pregunta de pensamiento interesante. Estamos hablando de atacar el navegador en lugar de atacar la aplicación y lo que está sucediendo dentro de la aplicación.

Ambos seguirán siendo importantes. La diferencia real desde la perspectiva del usuario final es que puede elegir qué navegador utilizar, qué aplicaciones web / proveedores buscar: usted tiene el control. En el lado de la aplicación web, este es realmente el problema del desarrollador.

Al leer la publicación original del blog, no me parece que esté sugiriendo que el navegador debería tener algún tipo de depuración en tiempo real para detectar XSS y CSRF. Creo que solo está señalando que la mayoría de los desarrolladores no se preocupan por la seguridad. Si bien puede usar XSS y CSRF para atacar un ataque Flash existente, lo que me viene a la mente a partir de su cita es alguien que instala un sitio de malware y lo lleva a ir allí: el sandboxing podría ayudar a que algunos códigos maliciosos escapen al sistema operativo. . Mientras que un ataque XSS suele ser contra un sitio y una aplicación legítimos que el atacante no controla directamente.

Otra posibilidad es que el autor haya visto recientemente a una compañía de AV hablar sobre cómo su caja de arena lo protegerá de las amenazas de Internet (lo he visto como una característica en algunas suites de AV recientes, un navegador de arena para sitios no confiables) y estaba enojado sobre el enfoque de nuevo en el usuario final. Desde la perspectiva del usuario final, solo puede evitar que XSS lo golpee en un conjunto limitado de casos, por ejemplo, obtiene un enlace que obviamente tiene un script configurado en un parámetro GET y elige no hacer clic en él o deshabilitar JavaScript y Cookies, etc. ; CSRF aún podría estar en juego.