Per quanto ho capito, una webapp è vulnerabile a RFD (Download di file riflessi) solo quando l'intestazione Content-Disposition: attachment che forza il download è impostata in una risposta con il corpo JSON,
ma in ogni caso vogliamo salvare un semplice file JSON nel computer dell'utente?
e dare un nome significativo a questo file tramite Content-Disposition: attachment; filename="whatever.txt" mitiga davvero l'attacco?
As far as I understand, a webapp is vulnerable to RFD (Reflected File Download) only when the header Content-Disposition: attachment which force the download is set in a response with JSON body,
Non necessariamente.
Vedi ad esempio questo articolo in cui si afferma che IE 8 e 9 scaricheranno tutto JSON come file e che l'attributo download su un link può essere utilizzato per forzare un download in altri browser.
Ho provato questo con una versione corrente di Firefox, e almeno lì, non funziona con l'origine incrociata (tranne tramite il tasto destro del mouse - > salva come). Se è possibile postare collegamenti HTML all'origine originale, è comunque possibile un attacco utilizzando Firefox. Non riesco a provare su Chrome, ma dovrebbe funzionare senza.
but in any case we want to save a plain JSON file in the user computer ?
Un utente malintenzionato vuole salvare un file sul computer degli utenti con un nome e un'estensione controllati e con il contenuto che almeno controllano parzialmente e desidera che questo file venga consegnato da un dominio trusted (dall'applicazione vulnerabile) in modo che un utente si fidi e lo esegua.
and giving a significant name to this file via
Content-Disposition: attachment; filename="whatever.txt"really mitigate the attack ?
Sì. L'idea di RFD è che un utente malintenzionato può determinare il nome file del file in modo che contenga un'estensione maligna. Se si imposta il nome file, non è possibile. Non sono a conoscenza di alcun bypass che consentirebbe a un utente malintenzionato di sovrascrivere il nome file specificato.
Leggi altre domande sui tag web-application