Evitar que el javascript proporcionado por el usuario se publique en un servidor externo

Question

Evitar que el javascript proporcionado por el usuario se publique en un servidor externo

#1 de rook (6 votos)
#2 de eckes (2 votos)
#3 de Dmitry Prokashev (1 votos)

8

Estoy escribiendo una herramienta interna que admitirá complementos escritos por otros desarrolladores. Idealmente, estos complementos tendrían un componente de Javascript para permitir que las personas creen widgets. Algunas de las páginas en las que operan estos widgets pueden contener datos confidenciales. Lo que quiero evitar es que el desarrollador escriba un complemento que tenga javascript que publique estos datos en algún servidor externo. Sin embargo, es esencial para el funcionamiento de estos widgets que puedan manipular los datos en la página. Básicamente, estos widgets solo deberían poder efectuar la presentación de los datos, pero no deberían poder robarlos.

He consultado adsafe, pero esto es demasiado restrictivo porque estos widgets solo pueden manipular el dominio provisto por el widget adsafe, por lo que no pudieron acceder a los datos que necesitan. También busqué en Google Caja, que podría ser una buena solución, aunque su compilación cruzada haría que el código se ejecute más lento en un entorno de rendimiento crítico (tampoco he jugado con él, así que no sé específicamente si puedo usarlo para evitar la publicación).

Creo que la solución "ideal" podría ser algún tipo de herramienta de análisis estático que pueda eliminar programas "simples" que intentan comunicarse con un servidor externo, pero acojo con agrado cualquier sugerencia que pueda funcionar.

web-browser javascript

pregunta user17619 20.12.2012 - 23:43

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-browser javascript

¿Cómo se puede detectar malware como Stuxnet? ¿Cómo diseñar una política de seguridad?

score 6 · Answer 1

El código es inherentemente dinámico y es y siempre será imposible controlar el comportamiento del código proporcionado por el usuario. Al permitir que los usuarios ejecuten JavaScript, está implementando una vulnerabilidad de secuencias de comandos entre sitios (XSS). XSS también se usa comúnmente para exponer a los usuarios a los Drive By Download que extrañamente falta en su modelo de amenaza.

Una forma de mitigar la amenaza planteada por XSS es aislar los scripts proporcionados por el usuario a un subdominio de manera que no puedan acceder a información confidencial debido a la Política del mismo origen . Esto no hace nada para detener a un atacante de ejecutar BeEF en usuarios de su aplicación web o realizar otro tipo de unidad mediante un ataque de descarga.

score 2 · Answer 2

2

Puede utilizar la Content-Security-Policy . Esto puede agregar algunas restricciones de script. Sin embargo, no todos los navegadores lo utilizan y es posible que no sea lo suficientemente detallado para usted.

respondido por el eckes 21.12.2012 - 05:52

fuente

score 1 · Answer 3

Recientemente creé una js-library ( enlace ) que podría ser adecuada para su propósito. La idea es la siguiente:

el código que no es de confianza se ejecuta en un entorno limitado (subproceso restringido en Node.js, o un trabajador web dentro de un iframe de espacio aislado para un navegador web);
el sandbox no tiene acceso a nada, pero puede "exponer" un conjunto de funciones externas en el sandbox, definiendo así precisamente la API y los permisos de lo que está permitido para que realice el código no confiable;
entonces el código puede llamar directamente a esas funciones para manipular o interactuar con la aplicación principal de la manera permitida (bajo el capó, esto se emula de forma aguda mediante un mecanismo de mensajería).

Esto también puede ser un poco inconveniente, lo que significa que si desea permitir una oportunidad para manipular los nodos DOM, por ejemplo, debe volver a describir explícitamente la API completa en términos de funciones exportadas.