Quiero usar node.js (u otra solución SSJS), ejecutando mi propio código + código externo escrito dentro (no es de confianza).Protección de SSJS contra código no verificado
¿Alguna manera de separar y proteger mi propio código? ¿Podría limitar los módulos y el efecto del sistema del código que no es de confianza (limitar el acceso a archivos, puertos que no sean HTTP, etc.)?
Se puede extraer de este proyecto, que parece muy prometedor:
http://github.com/gf3/node-sandbox
En lo personal, no uso Nodo hacer SSJS ejecución arbitraria. Probablemente no le guste esta solución, pero funcionó bien para mí durante aproximadamente un año:
Hay una implementación de Perl de la API de Spidermonkey (Spidermonkey es el motor JS de Firefox) that's available. Lo conecté con la ayuda de algunos CGI. Puede especificar exactamente qué funciones desea exponer (concedido, está en Perl ... blech) y ejecutar el código que desee. No hay riesgo de vulnerabilidades ya que toda la configuración está completamente aislada. No simula el DOM.
La forma en que implementé esto en mi servidor (para evitar abusos) fue emitir tokens que otorgaban acceso de un solo uso a través de una API REST en un servidor diferente. Es una implementación simple de HMAC que incluye una marca de tiempo para imponer la legitimidad del token. Cuando el script de Perl recibe una solicitud, valida el token y procesa el script (el script solo debe ser parte de una solicitud POST). El script de Perl simplemente escribe los resultados. Mi servidor está configurado para alcanzar un tiempo de espera de alrededor de 10 segundos.
Espero que esto ayude!
@Rook En realidad, estás equivocado. Ni siquiera es encriptación, es autenticación. Es la misma técnica que utiliza Amazon AWS. Más técnicamente, no es una "varita mágica criptográfica", es un medio legítimo para asegurar cualquier API REST frontal. No importa qué se use como secreto de HMAC. Súbase a cualquier generador de texto aleatorio y use los primeros 30 caracteres más o menos, no importa. Aunque has dejado en claro que no entiendes mucho sobre la seguridad. – mattbasta
@mattbasta crypto es la abreviatura de criptografía y una función de cifrado hash como sha256 pertenece a esta categoría. Claramente, la seguridad es un tema muy profundo y todos tienen más que aprender. Pero, en resumen, me desagrada mucho este enfoque para administrar una vulnerabilidad de ejecución remota de código. Hay una buena cita: "Si eval() es la respuesta, entonces estás haciendo una pregunta incorrecta". No hay absolutamente ninguna buena razón para que alguien esté ejecutando código como este. Es probable que el OP esté tomando un atajo y se queme con esta respuesta parcial. – rook
@Rook Por última vez, no es una vulnerabilidad. No hay "eval", ya que el código se está ejecutando en un entorno que literalmente no tiene nada que romper. Literalmente no hay medios para modificar información sensible, acceder al disco o realizar solicitudes de salida. Esa es la idea detrás de una caja de arena: claramente un tema que su profesor de seguridad debe haber descuidado. Claro, ejecutar el código en una declaración 'eval' es malo, pero si el OP desea ejecutar el JS de un usuario, entonces ejecutarlo en una configuración de espacio aislado es el medio más seguro y efectivo para lograr ese objetivo. Nombre una vulnerabilidad expuesta por un sandbox. – mattbasta
Eche un vistazo a Caja. Traduce el código de un tercero a un formulario donde el código solo tiene acceso a los objetos que le otorga explícitamente.
caja también es genial, solo tienes que esforzarte para engatusarlo y entender lo que estás haciendo (y necesitas Java, etc.) –
Salida esto desde la documentación Node.js
script.runInNewContext ([caja de arena])
similares a Script.runInNewContext (tenga en cuenta el capital 'S'), pero ahora es un método de un objeto Script precompilado. script.runInNewContext ejecuta el código de secuencia de comandos con sandbox como el objeto global y devuelve el resultado. El código en ejecución no tiene acceso al alcance local. sandbox es opcional
Ten cuidado, de los documentos actuales: ten en cuenta que ejecutar código que no es de confianza es un negocio complicado que requiere gran cuidado. Para evitar fugas de variables globales accidentales, script.runInNewContext es bastante útil **, pero la ejecución segura del código que no es de confianza requiere un proceso por separado **. –
Sí, pero realmente depende de cuán privilegiado sea el proceso actual para comenzar. Esto probablemente implica que creará un nuevo proceso con privilegios menores, que requiere más privilegios para comenzar (es decir, iniciar el daemon como raíz). Entonces, sí, poner en una caja de arena una ejecución global a un nuevo proceso es bueno, pero si estás corriendo como un usuario sin privilegios para comenzar probablemente estés bien. También depende de qué tan crítico sea esto. Si es el blog de tu gato, probablemente estés bien sea lo que sea que hagas. Si es un sitio compatible con PCI transaccional, sería un poco difícil. Realmente no dije en cuestión ... –
Wow que no ven js del lado del servidor con mucha frecuencia. ; – rook