Ho trovato xss su un campo textarea. Quando inserisci un carattere in questo campo, emette il carattere in tempo reale, quindi quando inserisco il seguente codice:
<input onclick=alert(document.cookie)>
non ci sono validazioni di input o filtri, quindi posso fare clic sul campo di input e su bam xss.
La mia domanda è se c'è una vera vulnerabilità in questo difetto? Non riesco a pensare a una vera vulnerabilità perché non posso inviare a una vittima questo link con il codice iniettato.
Se non puoi inviare il link, sarebbe un caso di self-xss che coinvolge la vittima iniettando snippet javascript dannosi, che è una non vulnerabilità in i bug bounties che ho incontrato o anche per valutazioni professionali. Tuttavia, in passato sono stati segnalati attacchi di social engineering in cui un utente malintenzionato convince qualcuno a incollare javascript dannosi promettendo alcuni risultati, ma in realtà finisce per causare danni alla vittima . Poiché ciò implica un lotto di interazione dell'utente , è principalmente una non vulnerabilità. Tuttavia, una protezione adeguata dovrebbe essere implementata in modo che l'input non sia riflesso in ogni caso.
Ulteriori informazioni su self-xss su: link
A volte sei fortunato e l'app è costruita in modo tale da trattenere il lato server dello stato di input e rifletterlo se rileva errori. Questo comportamento potrebbe non essere ovvio per impostazione predefinita poiché la convalida di javascript potrebbe impedirti di vedere quel postback (ma è stato aggiunto per far funzionare i browser non js).
Prova a vedere se l'input ha un parametro name e un link alla pagina (GET request) con il nome degli input come parametro query (test = nuovo nome qui). Se è tutto POST, basta disabilitare javascript nel browser e provare ad inserire il tuo XSS, e in un altro campo lasciarlo vuoto o inserire dati che sai non convalidare lato server. Il server può riflettere con i moduli già preparati con l'input precedente (che consente di riflettere il tuo XSS con un post CSRF). Se vengono implementati token CSRF, la tua unica fortuna è che la convalida del token sia successiva alla convalida dell'input (probabilmente no), o che i token possano essere riutilizzati. Ma se CSRF è permesso puoi probabilmente trovare un sacco di altre cose.
cant send a victim this link with the injected code
Questo potrebbe essere possibile se trovi che qualche input popolerà il campo.
Prova le richieste POST e GET per la pagina e prova a popolare il campo usando il suo nome (se ne ha uno), ma prova anche id e altre varianti. Dai un'occhiata al resto dell'applicazione e vedi se ci sono parametri comunemente usati che potrebbero essere provati qui. Lo strumento Burp Suite Target è ottimo per questo perché ti permette di vedere la mappa del sito a colpo d'occhio, insieme ai parametri inviati a ciascuna pagina.
Se ritieni che sia necessario utilizzare il metodo POST per compilare questo campo, per rendere possibile il collegamento potresti creare un modulo sul tuo sito da inviare al sito vulnerabile:
<form method="post" action="https://example.com/submit">
<input type="hidden" name="textarea1" value="<input onclick=alert(document.cookie)>" />
</form>
Potresti inviarlo automaticamente
<script>
document.forms[0].submit();
</script>
e devi semplicemente inviare il link della tua pagina alla tua vittima affinché l'XSS riflesso si attivi.
Leggi altre domande sui tag javascript exploit xss known-vulnerabilities