2010-01-27 9 views
7

que tenemos una aplicación Java y desea ejecutar código no confiable utilizando el construido en Javascript intérprete (javax.script. *)Cómo bloquear (o caja de arena) guiones que no se confía incorporados en Javascript intérprete para ejecutar de JDK

Sin embargo, de forma predeterminada, el intérprete permite el acceso a cualquier clase de Java. Por ejemplo, "java.lang.System.exit(0)" en el script cerrará la JVM. Creo que esto se llama "Conexión en vivo", consulte la "Guía del programador de scripts Java" de Sun para obtener más detalles.

me gustaría convertir de alguna manera fuera de la posibilidad de que la secuencia de comandos para acceder a las clases de Java, es decir, que sólo quieren el guión para poder acceder a los objetos que se inyectan específicamente en el uso de los métodos eval() o put() en ScriptEngine.

he encontrado alguna documentación sobre cómo lograr esto con mayor versión independiente del intérprete (Rhino), por ejemplo, ver http://codeutopia.net/blog/2009/01/02/sandboxing-rhino-in-java/

Sin embargo, este enfoque no es posible en el JDK 1.6 sin usar clases internas de sol, como el ClassShutter, etc., está configurado internamente y no puede anularse con métodos públicos.

Espero que haya una forma sencilla de evitar esto que no requiera saltar a través de aros complejos utilizando un SecurityManager personalizado, ClassLoader, etc. pero que no haya podido encontrar nada.

Usted esperaría con la frecuencia de los boletines de seguridad que rodean a Javascript en diferentes aplicaciones, ¡habría un simple indicador para deshabilitar Live Connect!

+0

Ver también: http://stackoverflow.com/questions/1347099/how-do-i-secure-scripts -run-using-javax-scripting – McDowell

+0

Todavía no puedo creer que en 2014 no haya una manera fácil de desactivar Live Connect for Java's ScriptEngine. He buscado y buscado sin suerte para encontrar una manera fácil de restringir el acceso.Estoy implementando una aplicación del lado del servidor que debería poder analizar el JavaScript proporcionado por el cliente usando JSR 223 y sin poder deshabilitar cosas como "' java.awt.Desktop.getDesktop() '" o "' java.lang.System.exit (0) '" es casi imposible de implementar. – chrixm

Respuesta

1

Busqué mucho, probé el blog sandboxing way de codeutopia.net y otras soluciones de SecurityManager, me sentí insatisfecho. Y luego salió mi solución de cargador de clases, basándose en la biblioteca de rhino integrada de JDK sin importar ninguna biblioteca de terceros. Dos clases de Java con aproximadamente 200 líneas de códigos, actualmente es la solución más simple que se ajusta a mi requisito de JavaScript.

  1. Estudia JavaScript motor de scripts nombre de clase de fábrica por ScriptEngineManager # getEngineFactories
  2. guión de carga de clase de fábrica del motor en un nuevo cargador de clases, en la que se tendrán en cuenta JavaMembers u otras clases relacionadas.
  3. Llamar #getScriptEngine en la secuencia de comandos del motor de script cargada y eval en el motor de script devuelto.

Si el script dado contiene el script Java, el cargador de clases intentará cargar JavaMembers u otras clases y desencadenar excepciones de clase no encontradas. De esta forma, las secuencias de comandos maliciosas se ignorarán sin ejecución.

Por favor leer archivos ConfigJSParser.java y ConfigJSClassLoader.java para más detalles:

https://github.com/webuzz/simpleconfig/tree/master/js/im/webuzz/config

Cuestiones relacionadas