Desde el punto de vista de la seguridad, ¿es una implementación de JavaScript en el navegador fundamentalmente diferente de una implementación de lenguaje del lado del servidor (por ejemplo, Python)?

  

¿Hay ataques que son posibles a través de código y datos no confiables, pero no solo a través de datos no confiables?

Si puede confiar en el código, generalmente puede usar este código de confianza para validar los datos que no son de confianza antes de seguir procesando los datos. Si el código no es de confianza, esto no es posible. Es por eso que el motor de Javascript dentro del navegador (que está ejecutando un código no confiable) se está ejecutando dentro de un entorno limitado (recinto de pruebas), de modo que el código no confiable no puede dañar el sistema subyacente. Esto significa, por ejemplo, que el acceso a archivos y redes está muy limitado.

Hay casos en los que el atacante logra inyectar su propio código en entornos de ejecución de confianza. Si este es el caso, el código de los atacantes tiene el mismo nivel de confianza que el otro código de confianza y, por lo tanto, puede causar un daño masivo dado que la suposición para el medio ambiente era que el código es confiable. Un ejemplo típico de dicha inyección es llamar a eval en los datos proporcionados por el atacante, interpretando así estos datos como un código confiable. .

  

En otras palabras, ¿es una tarea más simple asegurar una implementación de lenguaje solo contra datos maliciosos, en comparación con datos maliciosos y códigos maliciosos?

Sí, si se puede confiar plenamente en el código, no es necesario aplicar restricciones adicionales al entorno de ejecución, ya que se puede esperar que el código de confianza valide correctamente los datos que no son de confianza. Por supuesto, se recomiendan restricciones, sin embargo, como parte de la defensa en profundidad ya que la mayoría de los códigos complejos tienen errores.

Si, por otro lado, no se puede confiar en el código, es esencial limitar lo que puede hacer el entorno de ejecución. Esto lo hace más complejo ya que esta protección es necesaria además del idioma existente. Y, todos los errores en los últimos años dentro del Java Sandbox muestran que el diseño e implementar un entorno de ejecución tan restringido no es fácil.

  

¿Hay ataques que son posibles a través de código y datos no confiables, pero no solo a través de datos no confiables? Si es así, probablemente una implementación de Python puede permitirse ignorar estos tipos de ataques, pero una implementación de JS debería ser segura contra ellos.

Un ejemplo es la capacidad de medir el tiempo con alta precisión (temporizadores, bucles concurrentes). Se requiere que estos temporizadores exploten Specter , como vulnerabilidades. Para mitigar la vulnerabilidad, algunos navegadores reducen la resolución de los temporizadores de JavaScript. Un entorno de ejecución del lado del servidor no necesita tal restricción.