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="{"data": "<script>alert(123)</script>" }//" 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.