¿Es posible explotar las entradas de usuarios no escapadas en el formulario de JavaScript que solo obtiene datos a través de la solicitud AJAX?

2

Un usuario registrado puede acceder a una página https://example.com/some/page que tiene un campo de entrada y algunos botones. Cuando el usuario ingresa algo en este campo y hace clic en cualquier cosa, la página realiza solicitudes a https://example.com/data para verificar si el objeto solicitado está disponible y devuelve falso si no lo está.

En este caso, la página muestra una advertencia como Can't find $User Input$ . Entonces, si los usuarios ingresan algo como <script>alert(1)</script> , de hecho intentará procesarlo y mostrar una alerta. Lo que se llama "XSS reflejado", creo.

Así que aquí está la pregunta. En el ejemplo descrito estaban

  1. Claramente tenemos un campo de entrada sin filtrar que expone la vulnerabilidad de la reflexión XSS.
  2. Sin embargo, se requiere una entrada explícita por parte del usuario (ya que ninguna url puede llenar este campo, por ejemplo), ¿cómo debemos evaluar la gravedad de este problema?

Mi entendimiento general es que incluso si personalmente no sé cómo (si es posible) se puede usar este exploit, aún debería tratarlo como una vulnerabilidad crítica. Pero me faltan argumentos para probarlo para el triage.

    
pregunta Alex F 06.07.2015 - 18:56
fuente

4 respuestas

1

No se proporciona suficiente información para diagnosticar correctamente si se trata de una vulnerabilidad o no.

Si es posible engañar a un usuario para que haga la solicitud directamente a /data e incluya la carga maliciosa ( <script>alert(1)</script> ), entonces sí sería una vulnerabilidad si apareciera el cuadro de alerta.

Por ejemplo, engañando al usuario para que visite el sitio del atacante que contiene un redireccionamiento a https://example.com/data?<script>alert(1)</script> o contiene un formulario que POST a https://example.com/data con el cuerpo de la solicitud establecido en data=<script>alert(1)</script> .

Esto dependería de si /data responde también a solicitudes no AJAX. Además, el tipo de contenido devuelto debería ser text/html para que cualquier script sea procesado y ejecutado por el navegador.

Además, su carga útil podría representarse solo con un tipo de codificación de formulario de application/json . Si el controlador /data solo responde a las solicitudes con este tipo de codificación, es imposible realizar estas solicitudes con una etiqueta <form> .

Si aún se procesa la respuesta con un tipo de contenido diferente especificado, entonces es posible que pueda procesarla "engañándola" con una forma text/plain :

<form enctype="text/plain" method="post">

  <input type="hidden" name="{&quot;data&quot;: &quot;<script>alert(123)</script>&quot; }//" value="" />

  <input type="submit" />

</form>

La otra vía para explorar es si puede obtener /some/page para rellenar previamente el cuadro de texto con su carga útil. Pruebe parámetros comunes como:

  • https://example.com/some/page?data=<script>alert(123)</script>
  • https://example.com/some/page?value=<script>alert(123)</script>
  • https://example.com/some/page?<script>alert(123)</script>
  • https://example.com/some/page?debug=<script>alert(123)</script>
  • https://example.com/some/page?test=<script>alert(123)</script>
  • https://example.com/some/page?id=<script>alert(123)</script>
  • https://example.com/some/page?etc=<script>alert(123)</script>

Eche un vistazo a lo que ha observado en el resto del sitio (por ejemplo, consulte el mapa del sitio de Burp) y haga una lista de los nombres de parámetros más utilizados.

Consulte aquí para obtener mi respuesta a una pregunta similar .

Si no puede comprobar estas cosas por sí mismo, entonces necesitaría a alguien con habilidades de seguridad web para verificar si se trata de una vulnerabilidad o no. Si no es posible contratar a alguien, entonces sería mejor cubrir sus apuestas y arreglarlas de todos modos.

    
respondido por el SilverlightFox 07.07.2015 - 13:14
fuente
0

Algo sobre lo que pensar es si una persona malintencionada esencialmente puede engañar al usuario para que visite un sitio que imite o haga que el formulario se envíe con la información que el usuario malintencionado haya elegido (por ejemplo, explotar una vulnerabilidad de falsificación de solicitud entre sitios en al mismo tiempo). No se trata solo de generar una URL. En ese caso, se podría engañar al usuario para que ejecute un trozo de código peligroso en su navegador. No estoy seguro de cómo se ve o se ve tu aplicación, pero por el bien de tu evaluación & recomendación, considere si hay otras vulnerabilidades presentes que puedan exacerbar el problema.

    
respondido por el Tara Hodges 06.07.2015 - 19:23
fuente
0

Esto permite al usuario ejecutar js como cualquier persona que vea el mensaje sin filtrar, por lo que en teoría, si es el único que podrá ver este mensaje, esto no es un problema sino para cualquier forma que almacene datos visibles. por otro usuario es un problema.

Pero como he dicho antes, permite a cualquier sitio que su cliente visite para ejecutar código js dentro de su sesión de cliente para su sitio web. cómo hacer esto:

  1. enlace con param para obtener
  2. 303 con ubicación = obtener con param
  3. publicación de formulario html (puede publicar en cualquier dominio usando el formulario html)
  4. llamada ajax si el cliente desactiva la misma política de origen
respondido por el grandchamp robin 08.07.2015 - 11:45
fuente

Lea otras preguntas en las etiquetas