Scenario di download di file riflessi

1

Realizzo un'applicazione Web basata su Java che è intenzionalmente vulnerabile a Reflected File Download (RDF). Il white paper è qui Ho letto i requisiti della vulnerabilità del download di file riflessi come:

  • L'utente ha il controllo sul nome del file (manca il nome del file nell'intestazione content-disposition).
  • L'app
  • utilizza i valori trovati nell'URL (o in altri luoghi controllati dall'utente) per creare il contenuto del file. In altre parole, alcuni input dell'utente vengono "riflessi" sul contenuto della risposta.
  • La risposta
  • viene scaricata (anziché renderizzata nel browser) e un file viene "creato al volo", cioè in modo programmatico.

Ho un servlet chiamato FileDownload e non sto specificando il nome del file nell'intestazione content-disposition:

   response.setHeader("Content-Disposition","attachment");

In una richiesta ordinaria ( http://localhost:8080/FileDownload ), ottengo un file denominato FileDownload come previsto (sebbene abbia un'estensione .sql per motivi che non capisco)

Il pdf dice

Adding a "/" to the end of the path portion followed by a desired filename and extension is supported cross browser.

ma non ho immediatamente ottenuto questo comportamento, invece non è riuscito a trovare quella risorsa. Così, ho cambiato il mio web.xml da

<url-pattern>/FileDownload</url-pattern>

a

<url-pattern>/FileDownload/*</url-pattern>

e questo ha abilitato il comportamento descritto sopra nell'URL: http://localhost:8080/FileDownload/Setup.bat . Quindi, l'url-pattern deve essere extra permissivo perché funzioni?

Il documento asserisce anche che tutti gli avvisi "Questo tipo di file potrebbe danneggiare il computer ..." sono "ignorati" se una delle seguenti stringhe appare nel nome file: Installa, Imposta, Aggiorna, Uninst. Non ho visto questo comportamento. È cambiato da quando è stato rilasciato l'articolo?

Il punto di RFD sta abusando della fiducia di alcuni siti e se riesco a far apparire file arbitrari come se provenissero da un sito attendibile, posso ignorare certi avvertimenti. (È il mio browser che si fida già di determinati siti o è l'utente o entrambi?)

Sono rimasto sorpreso nel vedere quei pattern semi-colon come

http://localhost:8080/FileDownload;/Install.bat

http://localhost:8080/FileDownload;/Install.bat;Install.bat 

funziona come descritto nel documento. Tuttavia, se riesco a ottenere lo stesso risultato con http://localhost:8080/FileDownload/Install.bat , allora in quale scenario dovrei eseguire l'hack semi-colon?

Per fare tutto questo, ho anche dovuto impostare il mio browser per scaricare automaticamente i file senza chiedermi dove salvarli.

    
posta mcgyver5 11.11.2014 - 20:45
fonte

1 risposta

2

The point of RFD is abusing the trust of certain sites and if I can make arbitrary files look like they are coming from a trusted site, I get to bypass certain warnings. (Is it my browser that already trusts certain sites or is it the user or both?)

Penso che sia inteso solo perché l'utente guarderà il file scaricato e penserà "Oh, è venuto da www.google.com, quindi dovrebbe essere sicuro", e poi eseguirlo. Ma potrei sbagliarmi.

However, if I can achieve the same result with http://localhost:8080/FileDownload/Install.bat, then under what scenario would I need to do the semi-colon hack?

Hai usato IE / Firefox? La carta afferma nella sezione 2.2.2 che "hack" è necessario solo per Chrome / Opera. (Ma poi di nuovo, sembra che tu l'abbia risolto senza usare un singolo ";", che non è stato descritto nel documento.Il documento tuttavia afferma "Ovviamente, l'analisi specifica dell'URL dell'applicazione potrebbe portare ad altri caratteri accettabili come separatori nella porzione di percorso dell'URL. ").

    
risposta data 17.12.2014 - 00:39
fonte

Leggi altre domande sui tag