Stavo leggendo questo articolo qui , nel mezzo ho visto che l'autore ha usato -confirm()- come payload.
Mi piacerebbe sapere cos'è questo carico utile? Voglio dire qual è la differenza tra -confirm()- e <script>confirm()</script> . Perché funziona mentre <script>confirm()</script> non funziona?
Sarebbe molto apprezzato se qualcuno ci chiarisse qualcosa.
Il problema è il carattere di escape mancante \ nell'ultimo parametro.
Puoi provarlo con una funzione vuota:
<script>
function somefunction(){
//do nothing
}
somefunction( 'wskw='-confirm(1)-'');
somefunction( 'wskw='+confirm(2)+'');
somefunction( 'wskw='*confirm(3)*'');
somefunction( 'wskw='/confirm(4)/'');
somefunction( 'wskw='%confirm(5)%'');
</script>
È lo stesso di <script>confirm(1)</script> o <script>confirm(1)</script>
Puoi testarlo con questo violino: link
Generalmente l'input dovrebbe essere sempre codificato in url, come% 27 invece di '. Hanno dimenticato di sfuggire al secondo parametro.
'' chiude la stringa e dopo 'ci può essere qualsiasi codice JavaScript che verrà eseguito che deve essere incapsulato in uno qualsiasi dei seguenti operatori aritmetici JavaScript (-, +, *, /%). Quello che sta accadendo qui è un calcolo con il risultato della chiamata di funzione alert () o confirm () che deve essere eseguita per ottenere il risultato.
Poiché il codice è direttamente in questo modulo nel codice sorgente, viene generato sul lato server e c'è il problema con l'escape del parametro, non c'è direttamente un XSS vulnerabilità nelle librerie JavaScript. Teoricamente questo codice senza escape funziona con qualsiasi funzione e libreria in JavaScript. Il problema è la generazione del codice sul lato server.
<script type="text/javascript">
// Redirect click tracking
$.sliLinkTracker( ".redirect-link",'some_url_with_escape_characters', 'wskw='-confirm(1)-'');
</script>
In genere contatterei il proprietario del sito web e comunicarlo a loro in quanto ciò è fondamentale.
Leggi altre domande sui tag xss attack-vector