L'XSS riflesso funziona solo tramite Burp Repeater a causa della codifica dell'URL

Question

L'XSS riflesso funziona solo tramite Burp Repeater a causa della codifica dell'URL

#1 da (1 voti)
#2 da (1 voti)

2

Sono in grado di ottenere XSS riflesso attraverso il ripetitore burp utilizzando una richiesta GET. Quindi faccio clic su Mostra risposta nel browser e sono in grado di ricevere un avviso XSS. Ma quando vado manualmente all'URL nel mio browser il carico non viene eseguito!

Quando usavo payload come questo nel mio burp reapeater, ero in grado di ricevere un avviso:

"><html><body><script>alert("1")</script></body></html>

Ma quando vado allo stesso URL, come

https://example.com/exp="><html><body><script>alert("1")</script></body></html>'

viene codificato in

https%3A%2F%2Fexample.com%2Fexp%3D%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert%28%221%22%29%3C%2Fscript%3E%3C%2Fbody%3E%3C%2Fhtml%3E

nell'intercettore di burp e l'XSS non viene eseguito. Qualche soluzione per questo?

web-application xss reflected-xss burp-suite

posta Humble 09.02.2018 - 20:39

fonte

2 risposte

Leggi altre domande sui tag web-application xss reflected-xss burp-suite

suite di crittografia TLS / SSL Decodifica richieste da app Android potenzialmente dannose

score 1 · Answer 1

Ci sono due cose potenzialmente in corso qui:

1) Codifica URL : la maggior parte dei browser codifica qualsiasi carattere speciale nell'URL prima che venga trasmessa. Internet Explorer non codifica i caratteri nella stringa di query. Tuttavia, nell'esempio il carico utile si trova nel percorso. Per quanto ne so, tutti i browser moderni saranno codificati in URL, quindi non è utilizzabile.

2) Filtro XSS del browser : i browser più moderni (ma non Firefox) dispongono di filtri XSS che tentano di bloccare l'XSS riflesso. I filtri non sono a tenuta stagna e molti tester di penna li disattivano durante il test. Ti consiglio di riprodurre prima XSS con il filtro del browser disabilitato, prima di tentare di utilizzare un filtro bypass.

score 1 · Answer 2

È arrivato oggi in uno scenario simile. Dopo il debug, ho scoperto che la pagina Web vulnerabile stava riflettendo il percorso esatto dell'URL sulla pagina Web, rendendola vulnerabile agli XSS riflessi. I browser Web moderni codificano il percorso URL ogni volta e la variabile GET viene decodificata sul server. Ma in questo caso, lo script lato server non riflette alcuna specifica variabile GET ma l'intero percorso URL. Ad esempio seguente dovrebbe essere il codice PHP vulnerabile in quel caso.

<?php echo $_SERVER['REQUEST_URI']; ?>

Qui la variabile $_SERVER non interessa se l'input che sta ottenendo è o decodificato o codificato dall'URL, rifletterà solo così com'è. Quindi, poiché i browser moderni codificano l'URL per impostazione predefinita, sarà quasi impossibile sfruttarlo. Se trovi questo XSS mentre esegui il Penetration Testing per il tuo cliente, dovresti menzionarlo nel rapporto ma con un punteggio CVSS basso.

AFAIK, questo XSS non ha nulla a che fare con il filtro XSS come sopra risposto da PortSwigger.