Riesgos de seguridad al usar eval() para ejecutar la entrada del usuario en JavaScript

Question

Estoy planeando crear una página web rápida para que mis alumnos les enseñen sobre la programación de JavaScript. En esta página, me gustaría darles un cuadro de texto y permitirles ejecutar JavaScript para que puedan ver la naturaleza dinámica del idioma en funcionamiento. Sin embargo, soy muy consciente de que el uso de eval() en los comentarios de los usuarios suele ser una mala idea. ¿Qué tipo de riesgos de seguridad estoy asumiendo al publicar una página como esta? ¿Qué pasos debo tomar para mitigar estos riesgos?

Answer 1

Se ejecutará en su propia máquina. Simplemente no les permita guardar secuencias y enviarlas a otras personas; tampoco coloque los valores en la URL a través de un GET (para que pueda enviarse por correo electrónico).

Answer 2

Bueno, lo que eso significa es que cualquier código que un usuario quiera ejecutar en su formulario puede y bajo la autoridad del dominio bajo el que se ejecuta su sitio.

Así que si alguien quiere ejecutar código en una máquina que está bloqueada, pero confía en su sitio (por ejemplo, le permitiría ejecutar controles x activos, etc. etc.), esa persona podría hacerlo por escribiendo el código correcto y usando su sitio para evaluar el script en el espacio confiable. Esencialmente, al hacer esto, certifica que todo lo que se ejecuta en esa página se verifica como seguro para las personas que confían en su dominio. (Piense en sitios de confianza en IE, etc.)

Answer 3

Si está en una máquina local "desechable", existe un riesgo muy bajo. Como todo se está ejecutando en el lado del cliente, solo pueden dañarse a sí mismos con JavaScript. En el peor de los casos, podrían estar abriendo conexiones Ajax, pero eso no es mucho más dañino que darles un Firefox con el complemento Tamper Data.

En resumen, existe muy poco riesgo (excepto en cuanto a rendimiento) de darles dominio libre con JavaScript, excepto en la máquina que están utilizando, pero aún no es nada que no puedan hacer por sí mismos si son lo suficientemente astutos. Recomiendo hacer que lo ejecuten en sus propias máquinas, o en una caja de demostración que pueda volver a crear en cualquier momento cuando esté demasiado cargado de basura para seguir funcionando.

Ahora, darles acceso de evaluación a PHP/etc por otro lado sería una idea horrible, terrible.

Answer 4

El riesgo de seguridad que está tomando es que está recibiendo información del usuario y la está ejecutando en el contexto de un script en su sitio. Imagínese si usted fuera un cracker malicioso que por alguna razón tuviera acceso completo para modificar el JavaScript que se ejecuta en un sitio web. Puede hacer cualquier cosa que el JavaScript que se ejecute en su dominio pueda (incluido el robo de cookies, XSS, malware controlado, etc.).

Lo único que puede hacer de forma realista para mitigar los riesgos es no evaluar() el contenido proporcionado por el usuario. Los intentos de desinfectar la entrada para permitir solo la entrada "segura" están condenados al fracaso; es casi imposible definir lo que cuenta como seguro, y aún más difícil limitar el guión a eso (dado que el potencial atacante tiene un lenguaje interpretado con el que disimular sus intenciones).

Tenga en cuenta que, si esto es para fines educativos, entonces un enfoque es simplemente asegurarse de que todos los agujeros de seguridad no importen. El JavaScript incorrecto no puede destruir su servidor ni robar dinero de su cuenta bancaria (a menos que esté en la página web de su banco, por supuesto). Si el sitio que aloja la página no tiene cookies o sesiones que valga la pena robar, y los estudiantes saben que es solo un recurso educativo, no creo que haya nada de qué preocuparse. La mayoría de los ataques se basan en el acceso a la información confidencial almacenada en su dominio, o en engañar a los visitantes del dominio para que dejen de algún modo información confidencial (phishing ataques o similar). Para sus propósitos, creo que estará bien; simplemente no lo haga en un sitio web "real".

Answer 5

Le recomendaría que use la evaluación de entrada de todos los usuarios para evitar que el código evaluado acceda a todas las propiedades y métodos de objetos (ventana) globales.

Dale un vistazo a los siguientes recursos:

• Sandboxing JavaScript Using <iframe>
• google-caja

Answer 6

Realmente no hay riesgo serio aquí. Por ejemplo, abra firebug en esta página y escriba en la consola: eval("alert('hello');");, ¿problema? Realmente no.

Para propósitos de demostración esto no es un gran problema.

Answer 7

Puede intentar usar una biblioteca de espacio aislado de JavaScript. La solución de Dean Edward Caja no restringe el acceso del código a la ventana o documento actual. La biblioteca JSandbox ejecuta completamente la ejecución de código de cajas de arena usando Web Worker Threads (no podrá usar el DOM debido a esto) pero solo funciona en los navegadores que las admiten.

JSandbox es asíncrono, por lo que tendrá que cambiar el código para hacer uso de las devoluciones de llamada si elige usarlo.