¿Se puede usar un filtro de servlet de Java para extraer scripts que no están en la lista blanca?

3

Podría estar haciendo una pregunta similar a esta: Lista blanca de elementos DOM para derrotar XSS

Pero creo que mi solución propuesta es diferente y me preguntaba si podría hacer que la comunidad comentara si puede ser una forma efectiva de prevenir los ataques XSS.

Estoy personalizando un sistema de administración de contenido que tiene una línea de base de código grande (posiblemente cientos de Miles de líneas de código ejecutable). Debido a la naturaleza del desarrollo de COTs, es muy difícil para los desarrolladores realizar un seguimiento de todos y cada uno de los scripts que ejecuta el navegador.

¿Es posible incluir en la lista blanca los scripts usando un ServletFilter ?

Mi comprensión de un filtro de servlet es que ve todas las solicitudes y respuestas (es decir, todas las solicitudes y respuestas deben pasar por la cadena de filtros). He notado que las respuestas contienen etiquetas. Lo que significa que cuando todos los bytes del script se transfieren de nuevo al navegador del cliente desde el servidor, la intención es que el script se ejecute del lado del cliente. Ahí está mi oportunidad de realizar una comprobación de la lista blanca justo dentro del filtro de servlet antes que llega al cliente. Me gustaría asegurarme de que cualquier script de cualquier enviado al cliente esté en mi lista aprobada de scripts. Si no, el filtro modificaría la respuesta y sacaría el script allí mismo.

Ahora puedo pensar en un par de problemas con este enfoque. Primero, ¿cómo asignaría identificadores únicos a un script en particular que se puede agregar a una lista blanca en primer lugar?

El segundo problema es incluso si encuentro una manera de asignar identificadores únicos para un script en particular y agregarlos a la lista blanca, la lista blanca probablemente sea enorme (porque se trata de un producto COT que contiene posiblemente miles de scripts). Y si me olvido de poner un buen script en la lista blanca, habrá una funcionalidad rota.

Estos son los únicos problemas que se me ocurren con este enfoque. Me preguntaba si la comunidad podría comentarlo o hacer de esta una solución mejor.

    
pregunta user1068636 25.01.2014 - 01:17
fuente

1 respuesta

1

Solo hay una defensa real contra los scripts maliciosos, y es el escape de salida sensible al contexto. Primero necesitamos un par de definiciones:

  • Definición 1: Cada vez que la información del usuario se transfiera a otro intérprete de lenguaje dinámico, la transición de sus datos al intérprete en cuestión se llama Límite de seguridad.
  • Definición 2: Cada límite de seguridad tiene un Context específico, y este contexto define cuáles son las reglas para garantizar de manera segura que los datos que está entregando no serán ejecutado como codigo

La técnica que estás discutiendo es realmente un enfoque de filtrado de salida, tal vez donde solo permites que se importen scripts, es decir,

<script src="mydomain.com/somescript.js"/><script>

La respuesta corta es: Sí, podrías hacer eso, pero no sería un control "perfecto".

Además, si su aplicación permite el código html / script controlado por el usuario como parte de su función comercial, este enfoque es completamente efectivo.

    
respondido por el avgvstvs 28.01.2015 - 20:20
fuente

Lea otras preguntas en las etiquetas