Reflected XSS solo funciona a través de Burp Repeater debido a la codificación de URL

Question

Reflected XSS solo funciona a través de Burp Repeater debido a la codificación de URL

#1 de PortSwigger (1 votos)
#2 de Noman Riffat (1 votos)

2

Puedo obtener XSS reflejado a través del repetidor de eructos usando una solicitud GET. Luego hago clic en mostrar respuesta en el navegador y puedo recibir una alerta XSS. ¡Pero cuando voy manualmente a la URL en mi navegador, la carga útil no se ejecuta!

Cuando estaba usando cargas útiles como esta en mi repetidor de Burp, pude obtener una alerta:

"><html><body><script>alert("1")</script></body></html>

Pero cuando voy a la misma URL, como

https://example.com/exp="><html><body><script>alert("1")</script></body></html>'

se codifica en

https%3A%2F%2Fexample.com%2Fexp%3D%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert%28%221%22%29%3C%2Fscript%3E%3C%2Fbody%3E%3C%2Fhtml%3E

en el interceptor de eructos y el XSS no se ejecuta. ¿Alguna solución para esto?

web-application xss reflected-xss burp-suite

pregunta Humble 09.02.2018 - 20:39

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application xss reflected-xss burp-suite

¿Cuál es el mecanismo real cuando usamos VPN en HTTPS? eCryptfs: ¿qué pasa si elimino ~ / .ecryptfs

score 1 · Answer 1

Hay dos cosas potencialmente en juego aquí:

1) codificación de URL : la mayoría de los navegadores codifican cualquier carácter especial en la URL antes de que se transmita. Internet Explorer no codifica los caracteres de la URL en la cadena de consulta. Sin embargo, en su ejemplo, la carga útil está en la ruta. Por lo que sé, todos los navegadores modernos tendrán una codificación de URL, por lo que no es explotable.

2) Filtro XSS del navegador : la mayoría de los navegadores modernos (pero no Firefox) tienen filtros XSS que intentan bloquear el XSS reflejado. Los filtros no son impermeables, y muchos probadores de lápiz los desactivan durante la prueba. Le recomiendo que primero reproduzca XSS con el filtro del navegador deshabilitado, antes de intentar usar un filtro de omisión.

score 1 · Answer 2

Encontré un escenario similar hoy. Tras la depuración, descubrí que la página web vulnerable reflejaba la ruta URL exacta en la página web, lo que la hacía vulnerable a los XSS reflejados. Los navegadores web modernos codifican la ruta URL cada vez y la variable GET se descodifica en el servidor. Pero en este caso, el script del lado del servidor no refleja ninguna variable GET específica sino toda la ruta de la URL. Por ejemplo, lo siguiente debería ser un código PHP vulnerable en ese caso.

<?php echo $_SERVER['REQUEST_URI']; ?>

Aquí a la variable $_SERVER no le importa si la entrada que está obteniendo es una URL decodificada o codificada, solo se reflejará como está. Entonces, como los navegadores modernos codifican la URL de forma predeterminada, será casi imposible explotarla. Si encuentra este XSS mientras realiza pruebas de penetración para su cliente, debe mencionarlo en el informe pero con una puntuación CVSS baja.

AFAIK, este XSS no tiene nada que ver con el filtro XSS como fue respondido anteriormente por PortSwigger.