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.