2015-06-28 19 views
5

Questa potrebbe essere una domanda stupida e avere una risposta ovvia, ma stavo testando i miei 404 e 500 gestori di errori, il che significava che dovevo passare il debug a False. Sono andato alla pagina di amministrazione di Django e ho notato che i file statici non vengono serviti.Perché i file statici sono insicuri

Comprendo che devono essere instradati tramite Apache perché servono file statici tramite Django non è sicuro. Tuttavia, non capisco perché è un rischio per la sicurezza di servire file statici attraverso Django direttamente?

+1

Non penso che sia insicuro. Il vero problema è che è inefficiente. –

+0

Quindi è un po 'fuorviante usare l'argomento '--insecure' per forzare il servizio dei file statici con' debug = False' – Mirac7

+0

Direttamente si intende runserver? – cdvv7788

risposta

10

Ecco cosa la documentazione Django 1.8 dice sull'argomento:

--insecure

Utilizzare l'opzione --insecure per forzare porzione di file statici con l'app staticfiles anche se l'impostazione è DEBUGFalse. Usando questo si riconosce il fatto che è grossolanamente inefficiente e probabilmente insicuro. È destinato esclusivamente allo sviluppo locale, non dovrebbe mai essere utilizzato in produzione ed è disponibile solo se l'app staticfiles si trova nell'impostazione INSTALLED_APPS del progetto.

Come potete vedere, dicono "gravemente inefficiente" e "probabilmente insicuro". Non hanno detto "sicuramente insicuro" o "insicuro". Penso che quello a cui stanno suggerendo di non aver fatto un'analisi approfondita della sicurezza dell'app staticfiles e le sue interazioni con il resto di Django.

Per me, la parte "gravemente inefficiente" dovrebbe essere sufficiente a dissuadere dal servire il contenuto statico. È facile farlo meglio ... a partire dal comando collectstatic.


Alcuni più alla ricerca mi ha portato a questo post Google Gruppi, in risposta a qualcuno che chiedeva sul perché --insecure è insicuro.

Da: Malcolm Tredinnick

Nulla può essere considerato sicuro a meno che non è stato progettato e verificato per sicurezza. Non abbiamo fatto né con il file server statico. Non è possibile che abbia buchi di sicurezza esistenti, ma non dovrebbe essere considerato sicuro perché non è un obiettivo di progettazione.

Ad esempio, un file server sicuro dovrebbe verificare i problemi di allocazione delle risorse in modo che la pubblicazione di un file molto grande non costituisca un attacco denial-of-service . Ciò richiede un sacco di codice aggiuntivo e la gestione della pipeline che non vale la pena inserire in qualcosa che è solo per scopi di sviluppo.

saluti,

Malcolm

... che sostiene la mia interpretazione. (Ma non sono d'accordo con il modo in cui confonde sicurezza e vulnerabilità agli attacchi DoS.)

Problemi correlati