Reflected cross site scripting

Lo scripting  XSS si verifica quando un'applicazione riceve i dati in una richiesta HTTP e include tali dati nella risposta immediata in modo non sicuro.

Supponiamo che un sito web abbia una funzione di ricerca che riceve il termine di ricerca fornito dall'utente in un parametro URL:

https://insecure-website.com/search?term=gift

L'applicazione riproduce il termine di ricerca fornito nella risposta a questo URL:

<p>You searched for: gift</p>

Supponendo che l'applicazione non esegua nessun'altra elaborazione dei dati, un utente malintenzionato può costruire un attacco come questo:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

Questo URL produce la seguente risposta:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

Se un altro utente dell'applicazione richiede l'URL dell'aggressore, lo script fornito dall'aggressore verrà eseguito nel browser dell'utente vittima, nel contesto della sua sessione con l'applicazione.

Se un utente malintenzionato può controllare uno script che viene eseguito nel browser della vittima, in genere può compromettere completamente quell'utente. Tra le altre cose, l'attaccante può:

• Eseguire qualsiasi azione all'interno dell'applicazione che l'utente può eseguire.
• Visualizza tutte le informazioni che l'utente è in grado di visualizzare.
• Modificare qualsiasi informazione che l'utente è in grado di modificare.
• Avvia interazioni con altri utenti dell'applicazione, inclusi attacchi dannosi, che sembreranno provenire dall'utente vittima iniziale.

Esistono vari mezzi con cui un utente malintenzionato può indurre un utente vittima a fare una richiesta che controlla, per fornire un attacco XSS riflesso. Questi includono l'inserimento di collegamenti su un sito Web controllato dall'attaccante o su un altro sito Web che consente la generazione di contenuti o l'invio di un collegamento in un'e-mail, un tweet o un altro messaggio. L'attacco potrebbe essere mirato direttamente contro un utente noto o potrebbe essere un attacco indiscriminato contro qualsiasi utente dell'applicazione:

La necessità di un meccanismo di consegna esterno per l'attacco significa che l'impatto dell'XSS riflesso è generalmente meno grave dell'XSS archiviato , dove un attacco autonomo può essere consegnato all'interno dell'applicazione vulnerabile stessa.

Esistono molte diverse varietà di scripting cross-site riflessi. La posizione dei dati riflessi all'interno della risposta dell'applicazione determina il tipo di payload necessario per sfruttarlo e potrebbe anche influenzare l'impatto della vulnerabilità.

Inoltre, se l'applicazione esegue qualsiasi convalida o altra elaborazione sui dati inviati prima che vengano riflessi, ciò influirà generalmente sul tipo di payload XSS necessario.

La stragrande maggioranza delle vulnerabilità di cross-site scripting riflesse può essere rilevata in modo rapido e affidabile utilizzando lo scanner di vulnerabilità web di Burp Suite .

Il test manuale delle vulnerabilità XSS riflesse prevede i seguenti passaggi:

• Testa ogni punto di ingresso. Testare separatamente ogni punto di ingresso per i dati all'interno delle richieste HTTP dell'applicazione. Ciò include i parametri o altri dati all'interno della stringa di query dell'URL e del corpo del messaggio e il percorso del file dell'URL. Include anche intestazioni HTTP, sebbene un comportamento simile a XSS che può essere attivato solo tramite determinate intestazioni HTTP potrebbe non essere sfruttabile nella pratica.
• Invia valori alfanumerici casuali. Per ogni punto di ingresso, invia un valore casuale univoco e determina se il valore si riflette nella risposta. Il valore dovrebbe essere progettato per sopravvivere alla maggior parte della convalida dell'input, quindi deve essere abbastanza breve e contenere solo caratteri alfanumerici. Ma deve essere abbastanza lungo da rendere altamente improbabili corrispondenze accidentali all'interno della risposta. Normalmente l'ideale è un valore alfanumerico casuale di circa 8 caratteri. Puoi utilizzare i payload numerici di Burp Intruder  con valori esadecimali generati casualmente per generare valori casuali adeguati. E puoi usare l' opzione grep payloads di Burp Intruder per contrassegnare automaticamente le risposte che contengono il valore inviato.
• Determina il contesto di riflessione. Per ogni posizione all'interno della risposta in cui si riflette il valore casuale, determinare il suo contesto. Potrebbe essere nel testo tra tag HTML, all'interno di un attributo di tag che potrebbe essere tra virgolette, all'interno di una stringa JavaScript, ecc.
• In base al contesto della riflessione, testare un payload XSS candidato iniziale che attiverà l'esecuzione di JavaScript se viene riflesso non modificato nella risposta. Il modo più semplice per testare i payload è inviare la richiesta a Burp Repeater , modificare la richiesta per inserire il payload candidato, emettere la richiesta e quindi esaminare la risposta per vedere se il payload ha funzionato. Un modo efficiente di lavorare è lasciare il valore casuale originale nella richiesta e posizionare il payload XSS candidato prima o dopo di esso. Quindi imposta il valore casuale come termine di ricerca nella visualizzazione delle risposte di Burp Repeater. Burp evidenzierà ogni posizione in cui appare il termine di ricerca, permettendoti di individuare rapidamente il riflesso.
• Testare payload alternativi. Se il payload XSS candidato è stato modificato dall'applicazione o bloccato del tutto, sarà necessario testare payload alternativi e tecniche che potrebbero fornire un attacco XSS funzionante in base al contesto della riflessione e al tipo di convalida dell'input che viene eseguita. Per ulteriori dettagli, vedere contesti di scripting intersito
• Prova l'attacco in un browser. Infine, se riesci a trovare un payload che sembra funzionare all'interno di Burp Repeater, trasferisci l'attacco a un browser reale (incollando l'URL nella barra degli indirizzi o modificando la richiesta nella vista di intercettazione di Burp Proxy , e verifica se il JavaScript viene effettivamente eseguito. Spesso, è meglio eseguire un po 'di JavaScript semplice come alert(document.domain)che attiverà un popup visibile all'interno del browser se l'attacco ha successo.

Qual è la differenza tra XSS riflesso e XSS memorizzato? L'XSS riflesso si verifica quando un'applicazione riceve un input da una richiesta HTTP e incorpora quell'input nella risposta immediata in modo non sicuro. Con XSS memorizzato, l'applicazione invece memorizza l'input e lo incorpora in una risposta successiva in modo non sicuro.

Qual è la differenza tra XSS riflesso e XSS automatico? Self-XSS implica un comportamento dell'applicazione simile al normale XSS riflesso, tuttavia non può essere attivato normalmente tramite un URL predisposto o una richiesta interdominio. Invece, la vulnerabilità viene attivata solo se la vittima stessa invia il payload XSS dal proprio browser. Fornire un attacco XSS automatico normalmente comporta l'ingegnerizzazione sociale della vittima per incollare nel browser l'input fornito dall'aggressore. In quanto tale, è normalmente considerato un problema debole ea basso impatto.