Non ci sono abbastanza informazioni fornite per diagnosticare correttamente se si tratta di una vulnerabilità o meno.
Se era possibile ingannare un utente nel rendere la richiesta direttamente a /data e includere il payload dannoso ( <script>alert(1)</script> ), allora sì sarebbe una vulnerabilità se fosse visualizzata la finestra di avviso.
Ad esempio, inducendo l'utente a visitare il sito dell'attaccante che contiene un reindirizzamento a https://example.com/data?<script>alert(1)</script>
o contiene un modulo che POST a https://example.com/data con il corpo della richiesta impostato su
data=<script>alert(1)</script> .
Ciò dipende dal fatto che /data risponda anche a nessuna richiesta AJAX. Inoltre, il tipo di contenuto restituito dovrebbe essere text/html per ogni script da rendere ed eseguire dal browser.
Inoltre, il tuo payload potrebbe essere visualizzato solo con un tipo di codifica del modulo di application/json . Se il gestore /data risponde solo alle richieste con questo tipo di codifica, allora è impossibile effettuare queste richieste con un tag <form> .
Se esegue ancora il rendering della risposta con un tipo di contenuto diverso specificato, potresti essere in grado di renderlo "ingannandolo" con un modulo text/plain :
<form enctype="text/plain" method="post">
<input type="hidden" name="{"data": "<script>alert(123)</script>" }//" value="" />
<input type="submit" />
</form>
L'altra strada da esplorare è se puoi ottenere /some/page per precompilare la casella di testo con il tuo carico utile. Prova parametri comuni come:
-
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>
Dai un'occhiata a ciò che hai osservato sul resto del sito (ad esempio, controlla la mappa del sito di Burp) e crea un elenco di nomi di parametri comunemente utilizzati.
Vedi qui per la mia risposta a una domanda simile .
Se non riesci a controllare queste cose da te, allora avrai bisogno di qualcuno con competenze di sicurezza web per verificare se si tratta di una vulnerabilità o meno. Se non è possibile assumere qualcuno, allora sarebbe meglio coprire le tue scommesse e correggerlo comunque.