¿Pueden los proxies web diferenciar entre archivos JScript y Javascript?

1

Es una práctica recomendada relativamente común filtrar ejecutables y scripts de un usuario estándar en el nivel de proxy / gateway en el entorno corporativo. Si bien los archivos EXE / BAT / CMD son bastante fáciles, y podría decirse que .VBS (aunque supongo que en teoría podría usarse en un sitio web que solo es compatible con IEI), ¿existen soluciones sencillas para implementar JScript (.JS) de Microsoft? / p>

Parece complicado, ya que la extensión del archivo es la misma y el idioma es casi idéntico.

Alternativamente, ¿son necesarias las inspecciones de encabezado de tipo de contenido para verificar si se está descargando, en lugar de ejecutarse en el contexto del navegador web relativamente seguro / necesario?

¿O es la reconfiguración del sistema operativo evitar que la ejecución de archivos .js por wscript sea más común para mitigar esto? O inspección de contenido para detectar el uso de métodos peligrosos (la creación de instancias de objetos WScript viene a la mente).

Para su valor, estoy preocupado por la descarga y ejecución accidental de scripts maliciosos (pero no AV marcados) por los usuarios aquí.

    
pregunta user2867314 03.03.2017 - 13:28
fuente

1 respuesta

1

Según Wikipedia ( enlace ):

  

[Microsoft] no quería tratar con Sun Microsystems sobre el problema de la marca registrada, por lo que llamaron a su implementación JScript. Mucha gente piensa que JScript y JavaScript son lenguajes diferentes pero similares. Ese no es el caso. Son solo nombres diferentes para el mismo idioma, y la razón por la cual los nombres son diferentes fue para solucionar los problemas de marcas registradas

Entonces, para responder la pregunta en tu título, son la misma cosa.

Editar: Según el comentario a continuación de @dandavis, Jscript es realmente peor.

No sé nada acerca de Windows / IE, pero creo que puede configurar IE para que no ejecute JS (o solo para ciertos sitios), lo que significa que potencialmente solo podría permitir que JS se ejecute en sitios de confianza, lo que debería Limitar la superficie de ataque.

Si algo más que un navegador estaba descargando un poco de Javascript, puedes verificar qué es el User-Agent para la solicitud (aunque debes esperar que esté falsificado).

Creo que (pero, de nuevo, no en mi área) cosas como EMET podrían ser de alguna ayuda, como algo así como una lista blanca de aplicaciones (creo que la funcionalidad es parte de AppLocker, pero no sé hasta qué punto puede ayuda).

Siendo realistas, no creo que puedas bloquear globalmente Javascript, porque rompería una buena cantidad de sitios que la gente podría querer usar.

Editado para tener en cuenta la información adicional en el comentario a continuación:

Bien, en ese caso (gracias por especificar), creo que hay dos formas:

  • per enlace , parece posible deshabilitar las extensiones de shell, que creo que hace lo que usted quiere.

  • Esperaría (pero no sé) que EMET o AppLocker tuvieran algo en sus opciones para bloquear las llamadas de Wshell (creo que primero revisaría EMET)

Si tenía un proxy que podía hacer introspección de contenido (y no tener que lidiar con datos protegidos por TLS), podría bloquear secuencias de comandos específicas que contienen llamadas a wshell, pero como usted dice, eso es casi seguro para ser un juego largo de whack-a-mole que solo funciona en su mayoría.

Editar: se me ocurrió otra idea, que era tratar de obligar a los usuarios a seleccionar el directorio de descarga para las descargas de todas . Supongo que la mayoría se detendría al ver una descarga de .JS. Desafortunadamente, por enlace , esto ya no es posible para IE. Parece ser por ejemplo Chromium ( enlace ), pero eso probablemente no ayude. También es una protección bastante débil, y por esa razón puede ser un callejón sin salida.

    
respondido por el iwaseatenbyagrue 03.03.2017 - 14:02
fuente

Lea otras preguntas en las etiquetas