¿Por qué es JavaScript "seguro" para ejecutarse en el navegador?

El estándar está diseñado para ser seguro. La implementación puede no ser.

El navegador aísla JavaScript, ya que se ejecuta dentro de un proceso del navegador. No puede hacer nada que no esté permitido por el intérprete de JavaScript del navegador o el compilador JIT. Sin embargo, debido a su complejidad, no es raro encontrar vulnerabilidades que permitan a JavaScript comprometer el navegador y obtener ejecución de código arbitrario con los privilegios del proceso del navegador.

Debido a que estos tipos de errores de seguridad son tan comunes, muchos navegadores implementarán un sandbox. Este es un mecanismo de protección que intenta aislar un proceso de navegador comprometido y evitar que cause más daño. La forma en que funciona la caja de arena depende del navegador. Firefox tiene un sandboxing muy limitado, mientras que Chrome y Edge tienen un sandboxing importante. Sin embargo, a pesar de esta defensa en profundidad, las vulnerabilidades del navegador a menudo se pueden combinar con las vulnerabilidades de escape de la zona de pruebas.

  

¿Cómo es seguro?

No lo es. O más exactamente, es tan seguro como lo es la implementación del navegador. Los navegadores (incluido su motor de JavaScript) son piezas complejas de software, con la adición regular de nuevas características, porque los usuarios las quieren.

Eso significa que, incluso si los conocidos tienen procedimientos de calidad para probar su código contra vulnerabilidades conocidas, siempre existe el riesgo de una falla no detectada en la implementación de una función.

Actualmente, la forma aceptada es que tan pronto como se detecte una infracción, se lance una nueva versión que contenga un arreglo. Pero entre el descubrimiento de la brecha y la instalación de la solución, el navegador es vulnerable. Esa es la razón por la que se recomienda mantener el navegador actualizado para estar solo expuesto a zero-day vulnerabilidades.

Es cierto que a nivel de JavaScript, los navegadores están diseñados para proteger el código en ejecución (principalmente al no exponer ninguna API peligrosa), pero JavaScript es un lenguaje muy complejo para analizar y ejecutar .

ECMAScript es el estándar detrás de JavaScript, debido a la gran inflación de marketing en torno a los lenguajes de programación amigables para principiantes que estamos experimentando en la actualidad, el ECMAScript se está actualizando rápidamente e introduce funcionalidades cada vez más complejas para implementar en tiempo de ejecución.
Esto, a su vez, amplía la superficie de ataque y permite que los errores se introduzcan .

enlace

El blog describe el descubrimiento de un 0day que permite ejecución de código arbitrario en WebKit y cómo se usa para explotar otro 0day en el administrador de ventanas de macOS para escapar del sanbox en el que Safari se está ejecutando (eso es un macOS Sandbox, no uno de Safari) para escalar a "root" y ser dueño del sistema.
En pocas palabras, simplemente visitando un enlace mientras se habilita JavaScript, un sistema macOS se puede comprometer totalmente sin un solo fallo visible para el usuario.
Así de seguro puede ser JavaScript: tan seguro como una pieza compleja de software como puede ser el JSCore de WebKit.
Es por eso que a los usuarios que requieren alta seguridad se les recomienda desactivar JavaScript (ese es un requisito bastante común en DarkWeb, por ejemplo).

La vulnerabilidad en WebKit descubierta por los autores arriba es una condición de carrera entre el recolector de basura recién introducido y la función array.reverse : si el GC comienza a marcar una matriz mientras se está invirtiendo, podría llevar a un UAF (Usar después Libre) explotar. La marca se realiza secuencialmente en la matriz, supongamos que el GC está justo en el centro de la matriz cuando se invierte, la segunda mitad nunca se marca y, por lo tanto, se elige para la recopilación, lo que resulta en una UAF (el objeto de la matriz en sí no se recopila, solo su elemento).

La forma en que se usa una UAF para hacer primitivas de explotación más potentes que pueden conducir a la ejecución de código arbitrario es más o menos una variación de las mismas técnicas: primero se asigna un objeto interesante en el espacio recién liberado (por ejemplo, una matriz) y luego Se crea la primitiva RW (por ejemplo, modificando el límite de la matriz) y, finalmente, los códigos de operación arbitrarios se escriben en la memoria (por ejemplo, en una página JIT). Los detalles para este día en particular están en el blog vinculado.

La parte interesante es la forma en que se encontró este día: ya que WebKit es tan grande, es imposible realizar una revisión exhaustiva del código sin una gran cantidad de esfuerzo, por lo que se creó una fluctuación de fase automática.
Esto debe hacernos reflexionar sobre el hecho de que cuando tenemos cientos de miles o millones de líneas de código, es muy difícil hacer que cada una se comporte bien con respecto a las demás.

Como se indica en otras respuestas, cada navegador tiene su propio motor de script que está diseñado para la ejecución de JavaScript de sandbox y cada motor intenta limitar la funcionalidad de JavaScript que podría provocar un comportamiento malicioso.

Pero por regla general, JavaScript nunca ha estado seguro dentro del navegador. Los desarrolladores de códigos maliciosos encuentran constantemente formas de explotar cómo funciona cada motor, así como la funcionalidad de JavaScript disponible para lograr objetivos maliciosos.

En los primeros años, JavaScript era bastante peligroso dentro del navegador. Ahora es una carrera constante entre los desarrolladores de códigos maliciosos y los desarrolladores de motores / navegadores y, finalmente, los desarrolladores maliciosos siempre ganan, aunque sea por un corto tiempo. Así que JavaScript difícilmente puede ser llamado seguro. "Debería ser seguro por ahora" es una forma más precisa de decirlo.

  

JavaScript es bastante poderoso

Es por eso que muchos usuarios lo consideran inseguro y lo bloquean con las extensiones del navegador. JavaScript permite a los sitios web rastrear a los usuarios de formas que no son posibles sin incluir la identificación de los usuarios después de que hayan eliminado sus cookies mediante la huella digital del navegador. Muchas de las API web más nuevas, como WebUSB, permiten cosas que no son del todo seguras, pero los navegadores solicitarán el permiso del usuario cuando accedan a API inseguras como el USB y la cámara.

Es seguro en comparación con el código ejecutable a nivel de máquina, como los usos de ActiveX.

Un programa de código de máquina tiene acceso ilimitado a cualquier interfaz que el sistema operativo y las bibliotecas proporcionen a cualquier programa que se ejecute bajo esa cuenta de usuario, solo está REALMENTE restringido en lo que puede hacer por lo que el hardware y el sistema operativo lo restringen, esencialmente Un programa tan poderoso como el usuario que lo ejecuta. Puede haber herramientas que intenten restringirlo interceptando algunas de las interfaces proporcionadas, pero es difícil detener a un programa que tenga conocimiento de tales medidas para evitarlas.

El intérprete de javascript es parte del navegador y está escrito de manera que solo ofrece el programa que ejecuta las interfaces y los poderes que quiere ofrecerles.

JavaScript es "relativamente seguro", pero no "absolutamente seguro". Cualquier código que ejecute en su sistema puede hacer daño. No existe un sistema perfectamente seguro, excepto el que nunca se usó. JavaScript es más seguro que poner un dispositivo USB desconocido en su computadora, y más seguro que un binario que descarga desde un sitio web sospechoso o recibe un archivo adjunto sospechoso en el correo electrónico, y mucho más seguro que algunos de los scripts que encontrará en los sitios web que le indican que cópialo y pégalos en tu shell.

Tiene características de seguridad: una zona de pruebas para ayudar a aislar el proceso, una API relativamente limitada que tiene restricciones de seguridad para evitar la ejecución de instrucciones informáticas arbitrarias y controles de seguridad destinados a limitar la exposición de datos confidenciales como huellas dactilares o intercambio de datos entre dominios . Estos se encuentran en la parte superior de los controles de su sistema operativo aplicados al binario del navegador para limitar el mal comportamiento y las aplicaciones antivirus que pueden ayudar a detener dichos ataques.

Sin embargo, no es absolutamente seguro. Los errores en el motor de ejecución del navegador, el navegador mismo, el antivirus o incluso el propio procesador pueden poner en peligro la seguridad de JavaScript. El sistema es tan seguro como su seguridad más débil. La seguridad de JavaScript está pensada principalmente para evitar explotaciones "informales" (como un JavaScript de aprendizaje de 8 años por primera vez y escribir accidentalmente una vulnerabilidad), pero no tiene ninguna posibilidad contra atacantes dedicados. JavaScript es lo suficientemente complicado como para que haya errores, tal vez de formas extrañas e inesperadas.

Aquellos que tienen experiencia en piratería, pruebas de pluma y seguridad pueden, y lo hacen, navegar a través del código fuente, depurar ejecutables y hacer todo lo posible para tratar de encontrar problemas en la armadura. Los puntos débiles de la implementación de JavaScript. Y JavaScript es lo suficientemente grande como para que existan tales puntos de partida, ya que es prácticamente imposible incluso automatizar todas las pruebas posibles que podrían encontrar estos errores.

En términos generales, cualquier script típico que pueda encontrar en un sitio web típico es probablemente "seguro", especialmente aquellos vinculados a los principales motores de búsqueda. Sin embargo, una vez que comience a desviarse, es muy probable que su sistema se vea comprometido en algún momento, incluso si hay un solo punto débil. Solo se necesita un buen exploit, o a veces dos o tres en conjunto, para asumir completamente un sistema.

Tal como está, solo habilite JavaScript para los sitios en los que confía (personalmente uso NoScript para este propósito), siempre mantenga actualizado todo su software y preste atención a las advertencias del navegador, como certificados no válidos, etc. Incluso entonces, no estará 100% seguro, pero participará activamente en su propia estrategia de mitigación.

No hay nada inherentemente seguro acerca de JavaScript, en muchos aspectos es menos seguro que en otros idiomas:

• sentencia eval
• escritura dinámica

Es la caja de arena donde el navegador ejecuta el JavaScript que proporciona la seguridad. Consulte la documentación en el espacio aislado de Chrome aquí , observe que no hay ninguna referencia a JavaScript o script ECMA.

Hoy en día, la gran mayoría de los códigos que se ejecutan en el navegador están escritos en JavaScript. Con el aumento de WebAssembly , es probable que veamos el cambio de la plataforma del navegador desde el bloqueo de un idioma principalmente único de hoy (como un mainframe del pasado) a una plataforma abierta donde se puede utilizar cualquier lenguaje compatible con WebAssembly. Esto, de alguna manera, demostrará que JavaScript no es particularmente seguro / especial, ya que en ese momento se ejecutarán muchos idiomas en el navegador. Todos estos idiomas utilizarán el sandbox que proporciona el navegador para ejecutar.

Esta respuesta abordará dos puntos planteados en la pregunta y una "característica" del navegador que no se mencionó en la pregunta.

  

JavaScript tiene ciertas limitaciones, como evitar la lectura y   escribiendo en el disco

dicha limitación no existe técnicamente en los navegadores Chromium / Chrome donde se define requestFileSystem , que escribe directamente en el disco; es decir, la carpeta File System del directorio de configuración de Chromium / Chrome en el sistema de archivos de los usuarios.

Consulte Cómo escribir en un archivo (directorio de usuario) utilizando JavaScript?

  

y no permite el acceso a otras ventanas o dominios del navegador.

Si se abre window desde un window ya abierto, es posible la comunicación entre window s usando, pero sin limitarse a, postMessage , MessageChannel , SharedWorker , o simplemente consulte parámetros de cadena.

Consulte ¿Cómo puedo ¿cargar un trabajador web compartido con un script de usuario?

Otro punto no mencionado en el OP que debe plantearse aquí específicamente para Chromium / Chrome es el hecho de que la implementación SpeechRecognition de Web Speech API en esos navegadores registra la voz de los usuarios (identificador biométrico) y envía esa grabación a un servicio remoto, sin avisar directamente al usuario de lo que está ocurriendo. No está claro de inmediato si las grabaciones son retenidas (para siempre) por el "servicio web" no revelado o "eliminado" en algún momento.

Consulte ¿WebkitSpeechRecognition envía audio grabado a un servicio web remoto de forma predeterminada?

Es seguro porque fue diseñado para ser seguro. O al menos es seguro hasta el punto en que un "JavaScript es bastante poderoso" no muy formal, sugiere que es probablemente lo suficientemente seguro como para tranquilizarlo. En la práctica, ningún software es perfectamente seguro, por lo que es una cuestión de grado. Javascript es lo suficientemente seguro como para que la mayoría de las empresas estén dispuestas a permitir que los empleados visiten sitios web utilizando el hardware de la compañía.

JavaScript está diseñado para evitar que los atacantes obtengan acceso a sus archivos o cualquier información privada. Por ejemplo, tiene soporte para evitar que una secuencia de comandos en un sitio mire los datos de otro sitio (conocido como ataque entre sitios).

Por supuesto, esto no es perfecto. Hubo un susto reciente con Spectre y Meltdown , un par de exploits que se basan en una falla en algunos procesadores para liberarse de la caja de arena que JavaScript ejecuta. Debía ser parcheado con algunos hacks de software bastante feos para cubrir Los procesadores defectuosos.

Pero en general, es "seguro" ejecutar tales scripts porque muchos expertos en seguridad han pasado mucho tiempo asegurándose de que la sensación de seguridad esté justificada. Pero todo depende de tu modelo de amenaza. Si tuviera miles de millones de dólares en la línea, ¡tal vez ni siquiera quiera confiar en la seguridad de JavaScript!

Entonces, la verdadera pregunta es ¿cuál es tu barra para "seguro"? ¿Considera Windows para estar seguro? ¿Qué hay de Internet Explorer ? Adobe Acrobat Reader ? OpenJPEG ? ¿El kernel de Linux ? OpenSSL ? La seguridad y la facilidad de uso están siempre en desacuerdo. Tienes que usar algo (o tal vez no. A los Amish todavía no les ha tocado un día de 0 días ... a menos que cuentes una nueva cepa de Influenza) Para entender realmente si puedes decir que algo es "seguro" o no necesita un modelo de amenaza, que defina cómo alguien podría atacarle, y un modelo de usabilidad que define qué usabilidad necesita lograr mientras mitiga el modelo de amenaza. Sin eso, tenemos que leer tus palabras y tu historial para adivinar qué significa "seguro".