¿Por qué es mala la salida no saneada de una solicitud ajax?

Question

¿Por qué es mala la salida no saneada de una solicitud ajax?

#1 de PlasmaSauna (2 votos)
#2 de dandavis (1 votos)

1

Sé que lo que acabo de describir es una vulnerabilidad XSS reflejada. Lo que no puedo entender es por qué es una vulnerabilidad. Debido a la forma en que lo veo, un usuario no puede ser dirigido al contenido del atacante porque AJAX se ejecuta sin una actualización de página o un cambio de URL. ¿Qué me estoy perdiendo aquí?

- EDITAR -

Para editar la pregunta y proporcionar un poco más de contexto, estoy tratando de averiguar cómo hacer eco en la página de los datos no desinfectados de AJAX sería algo malo. Porque aquí es como veo las vulnerabilidades de XSS:

JavaScript de una fuente no controlada (es decir, un atacante) puede insertar JavaScript en la página.
El usuario se desplaza a dicha página con el malvado JavaScript incrustado en la página.
Ocurre una explotación (se roban las cookies, los inicios de sesión de los usuarios en la pantalla de inicio de sesión de un atacante, etc.)

No puedo ver cómo esto es un problema con AJAX. Debido a que la solicitud se realiza en la página y usted (como atacante) no puede dirigir a un usuario a una página donde se cargó parte del contenido con AJAX.

O, en otras palabras, no puede realizar una consulta de búsqueda en un motor de búsqueda que usa AJAX para consultar un punto final remoto y mostrar los resultados en la página, luego dirigir a un usuario a esa página con los resultados mostrados. Los resultados desaparecerían.

¿Qué me estoy perdiendo aquí?

xss reflected-xss

pregunta Adam McGurk 26.07.2018 - 20:42

fuente

2 respuestas

1

depende de lo que haga la aplicación con el retorno ajax. por ejemplo, jQuery $(selector).html(ajaxContent) Llamará a eval() (o un equivalente) en cadenas en la respuesta entre <script> y </script> , bajo ciertos tipos mime. Obviamente, eso ejecuta un código arbitrario que puede robar cookies, redirigir a sitios malos, intentar descargar malware, lo que sea.

respondido por el dandavis 26.07.2018 - 20:58

fuente

Lea otras preguntas en las etiquetas xss reflected-xss

¿Cómo funcionan los sitios web CORS proxy? ¿Debo firmar las claves de lanzamiento del software con mi propia clave?

score 2 · Accepted Answer

Tu primer punto ("JavaScript de una fuente no controlada (es decir, un atacante) puede insertar JavaScript en la página") está un poquito apagado. Si una página ya contiene JavaScript de un atacante, el atacante ya ha ganado.

Una descripción más precisa de un ataque XSS reflejado es:

El usuario se desplaza a una página que acepta la entrada del usuario, de manera que el usuario proporciona de manera involuntaria parte de la entrada.
JavaScript de una fuente controlada (es decir, el desarrollador de la aplicación web) toma datos de la entrada del usuario y los inserta en la página.
La entrada del usuario del Paso 1 se interpreta como JavaScript (se roban las cookies, etc.).

Para proporcionar un ejemplo de cómo podría funcionar su escenario, considere una aplicación web que permita a los usuarios marcar los resultados de búsqueda colocando el término de búsqueda en la cadena de consulta: https://my-custom-search-engine.tld/search?term=reflected%20xss

Al cargar la página /search , JavaScript en la página lee el parámetro de consulta term y realiza una solicitud AJAX. Al recibir la respuesta, JavaScript en la página lee la parte del término de búsqueda del objeto de respuesta y lo inyecta en la página utilizando un método vulnerable. (Vea la respuesta de @dandavis para jQuery's .html , o jpg> a para ver otros métodos peligrosos.)

En este ejemplo, un atacante tendría que engañar a un usuario para que visite https://my-custom-search-engine.tld/search?term=<script>alert(1)</script> .