¿El XSS reflejado sigue siendo relevante hoy?

El XSS reflejado no es solo por GET. Puede ser por POST también. Y no se evitan siempre por los navegadores. Y por supuesto, sigue siendo relevante.

Un par de definiciones:

• enlace
• enlace

Y, a partir de la base de conocimientos de Checkmarx, dice: " el XSS más comúnmente encontrado ". Extraído de aquí . Entonces, si es el más común, creo que todavía es relevante.

Sí, todas las formas de XSS siguen siendo relevantes hoy.

El ataque en particular que intentaste era obvio para el navegador para heurísticamente , pero el código generado por inyecciones más sutiles podría no serlo. ¿Qué sucede si cambio la URL de envío de un formulario porque el desarrollador usó <form action="{$_SERVER['PHP_SELF']}" ? ¿Qué pasa si cambio su mensaje de error a un mensaje de confirmación? ¿Qué sucede si cambio el hash SHA1 de una distribución de Linux que ha descargado?

Nunca confíe en las características del lado del cliente (en particular los navegadores web) para brindar seguridad a sus usuarios.

Los casos más comunes y triviales de XSS reflejados, donde literalmente se imprime exactamente lo que se proporcionó ( <?php echo $_GET['query']; ?> ) y se ejecuta como está, no son prácticamente relevantes en los navegadores modernos de forma predeterminada, no.

Sin embargo, "XSS reflejado" como categoría es un poco más amplio que eso. También incluye casos en los que la entrada está codificada de alguna manera. Un ejemplo que he visto en el mundo salvaje es el reflejo de HTML codificado en base64, como <?php echo base64_decode($_GET['query']); ?> . Los filtros del navegador probablemente no lo capten.

También debe tener en cuenta los casos en que el código no se ejecuta por sí solo, pero hay algún otro JavaScript que hará que se ejecute más tarde. La forma más común en que esto puede suceder es en una biblioteca de plantillas del lado del cliente que interpreta expresiones en lo que de otro modo sería texto estático. Por ejemplo, considere este caso donde los atributos dyn- se evalúan del lado del cliente con algunos datos del modelo:

<img dyn-src="model.get('<?php echo $_GET['name']; ?>')" />
<script>
  let model = { something... };
  for (let el of document.querySelectorAll('[dyn-src]')) {
    el.src = eval(el.getAttribute('dyn-src'));
  }
</script>

Esto permite una forma de XSS reflejado con algo como ?name=', alert('xss'), ' , que los navegadores probablemente tampoco detectarán.

El XSS reflejado sigue siendo relevante porque no todos los navegadores implementan los mismos filtros de la misma manera, algunas veces se descubre un bypass para algunas implementaciones, por lo que el auditor no puede bloquearlo.

Algunos sitios no tienen el encabezado X-XSS-Protection habilitado, por lo que esos sitios también son vulnerables

Y, como se dijo en otra respuesta, la carga útil se puede entregar a través de POST en lugar de GET , evitando que el auditor bloquee la inyección maliciosa

Finalmente, incluso si todo está configurado correctamente y no hay una omisión conocida para la implementación del filtro, es solo un filtro. Bloquea ciertos XSS reflejados, pero como hay falsos positivos, también hay falsos negativos, por lo tanto, la carga útil permanece sin ser detectada

Sí.

Por un lado, Firefox aún no tiene un filtro XSS, por lo que los ataques reflejados se pueden ejecutar en este navegador.

Además, XSS basado en DOM omite los filtros del navegador. Esto no se clasifica estrictamente como "XSS reflejado" , sin embargo, el resultado final es el mismo.

Otra cosa a tener en cuenta es que los auditores del navegador XSS no constituyen un límite de seguridad. De Google :

  

No, las omisiones del auditor XSS no constituyen seguridad de Chrome   vulnerabilidades (por lo que este error está marcado como SecSeverity-None).   Puede encontrar nuestras pautas de severidad aquí:    enlace

     

Para aclarar un poco más, el auditor de XSS es un mecanismo de defensa en profundidad   para proteger a nuestros usuarios contra algunas vulnerabilidades comunes de XSS en la web   sitios Sabemos a ciencia cierta que no puede capturar todas las variantes posibles de XSS,   y los que atrapa todavía necesitan ser reparados en el sitio afectado.   Entonces, el auditor es realmente una red de seguridad adicional para nuestros usuarios, pero   no pretende ser un mecanismo de seguridad fuerte.

Hay omisiones en estos mecanismos del navegador todo el tiempo. ejemplo de IE aquí . Y, en oposición a otra respuesta aquí, los filtros intentan bloquear las solicitudes POST también . Sin embargo, nunca puede confiar en estos filtros para bloquear todos los XSS.

El resultado final es que debe mitigar XSS en su aplicación web mediante el uso de codificación de salida, filtrado / validación de entrada (si es posible) y, con suerte, una política de seguridad de contenido sólida.

El filtrado y la validación de la entrada a veces pueden ser complicados, sin embargo, si está ingresando datos en los que la única entrada válida son los números y las letras, si desea una aplicación segura, es una buena idea restringir los conjuntos de caracteres solo a aquellos que son útiles. Por supuesto, esto no es posible si está ejecutando un sitio de estilo de desbordamiento de pila en el que está permitiendo fragmentos de código y los que utilizan un gran conjunto de caracteres.

Recuerde que el XSS reflejado requiere que un usuario siga o sea redirigido a una URL. Por lo tanto, a veces se necesita un poco de "ingeniería social" de un atacante para explotar. Por lo general, clasifico el XSS reflejado como una vulnerabilidad de riesgo medio, a menos que pueda explotarse automáticamente desde la aplicación (digamos un redireccionamiento automático en algún lugar) o si la aplicación en sí es particularmente sensible.

Sí :

• No arreglar las vulnerabilidades de seguridad conocidas siempre es una mala idea, pero también ...
• Los principales navegadores que intentaron bloquear el XSS reflejado están considerando retirar la tecnología.

Entiendo de dónde viene esta pregunta, pero desafortunadamente la tecnología no es perfecta y casi nunca detiene a un atacante determinado:

  

En los últimos 3 meses, examinamos todos los errores internos de XSS que activaron a XSSAuditor y pudimos encontrar desvíos para todos ellos.

Ese es el equipo en Chromium, anunciando que recomiendan a Chrome que retire a XSSAuditor . La razón dada es la siguiente:

  

No hemos encontrado ninguna evidencia de que XSSAuditor detenga ningún XSS, y en su lugar hemos tenido dificultades para explicar a los desarrolladores a escala, por qué deberían corregir los errores incluso cuando el navegador dice que se detuvo el ataque.

Y no solo hace que los desarrolladores se pregunten si deberían aplicar arreglos, sino que también hace que los evaluadores de seguridad hagan su trabajo menos bien. Ya que les resulta difícil justificar cómo es un riesgo sin encontrar un bypass (a veces lento):

  

Además, hemos examinado los pentesters de seguridad y descubrimos que algunos no reportan vulnerabilidades a menos que puedan encontrar un bypass para el auditor de XS, lo que significa que los equipos de defensa terminan siendo discapacitados incluso más que los atacantes (como los equipos de defensa ya que los equipos de defensa necesitan para ampliar sus esfuerzos de remediación, mientras que los atacantes solo necesitan algo que funcione).

Microsoft es menos comunicativo con respecto a su razonamiento, pero también anunció en junio pasado que retirarán el filtro XSS :

  

Filtro XSS retirado: estamos retirando el filtro XSS en Microsoft Edge a partir de la compilación de hoy. Nuestros clientes permanecen protegidos gracias a los estándares modernos como Política de seguridad de contenido , que ofrecen más poder mecanismos seguros y eficaces para proteger contra ataques de inyección de contenido, con alta compatibilidad en navegadores modernos .

Otra buena publicación de blog sobre el tema es esta: enlace < br> Por ejemplo, enlaza con investigaciones que muestran que el filtro XSS en MSIE a veces conduce a vulnerabilidades que de otra forma no se podrían explotar.

Sí, esto sigue siendo relevante. Puedes intentar seguir para tu muestra:

http://localhost:8082/?query=<svg onload="alert('Hello!')"/>

Tampoco hay ninguna razón para que alguien que intente un pirateo no solo use un navegador que no tenga la protección XSS incorporada. Incluso si no hay un navegador antiguo que funcione, siempre pueden obtener la fuente de los nuevos y Deja fuera esas protecciones.

Siempre es una mala idea confiar en las restricciones del lado del cliente para detener cualquier tipo de explotación. El cliente no está bajo su control, y nunca lo estará. El hacker siempre puede modificar su propia computadora.