Come risolvere le 10 principali vulnerabilità di sicurezza di Django

Il popolare framework Python di alto livello Django è ampiamente lodato per la sua facilità d'uso e il design pragmatico, ma come tutti i software è suscettibile alla propria quota di vulnerabilità critiche. Costruito completamente con Python, il framework MVC ha una comunità considerevole e può essere esteso con plug-in di app per funzionalità aggiuntive. L'ubiquità ha il suo prezzo, tuttavia: in questo caso, la popolarità open source di Django significa che anche i vettori di attacco predefiniti sono ampiamente noti.

Il livello dell'applicazione è sempre più preso di mira dagli hacker per la penetrazione e l'esecuzione di Python full stack non è né più/meno vulnerabile di qualsiasi altro stack di applicazioni. Infatti, BitBucket, dpaste e il supporto di Mozilla utilizzano tutti Python/Django per le loro offerte web mission-critical, quindi non temete: un'efficace gestione delle vulnerabilità e la visibilità delle lacune di sicurezza esistenti di Django possono fare molto per rafforzare la vostra applicazione web basata su Django contro gli attacchi.

Dai un'occhiata al nostro articolo Full Stack Blues per conoscere le vulnerabilità in altri stack di applicazioni.

Le 10 principali vulnerabilità di Django

10. Modifica della sessione (CVE-2011-4136)

Versioni 1.2.7 e 1.3.x precedenti alla 1.3.1

Quando i dettagli della sessione vengono archiviati nella cache, la spaziatura dei nomi radice viene utilizzata sia per gli identificatori di sessione che per le chiavi dei dati dell'applicazione. In questo modo gli utenti malintenzionati remoti possono modificare una sessione attivando l'uso di una chiave uguale all'identificatore di tale sessione.

9. Dirottamento della sessione (CVE-2014-0482)

Versioni 1.4.14, 1.5.x prima della 1.5.9, 1.6.x prima della 1.6.6 e 1.7 prima della release candidate 3.

Il dirottamento della sessione comporta l'accesso non autorizzato di un utente malintenzionato a un sistema utilizzando i dati della sessione di un altro utente. In questo caso, quando si utilizza contrib.auth.backends.RemoteUserBackend, gli utenti autenticati remoti possono dirottare le sessioni web tramite vettori correlati all'intestazione REMOTE_USER.

8. Avvelenamento della cache (CVE-2014-1418)

Versioni 1.4 prima di 1.4.13, 1.5 prima di 1.5.8, 1.6 prima di 1.6.5 e 1.7 prima di 1.7b4

L'avvelenamento della cache si verifica quando vengono inseriti dati errati nella cache di un resolver DNS, causando l'immissione da parte del server dei nomi di un indirizzo IP o di una destinazione errati. Queste versioni di Django non includono correttamente:

Varia: Cookie
Intestazione Cache-Control in risposta

Ciò può consentire agli aggressori remoti di ottenere informazioni sensibili o avvelenare la cache tramite una richiesta da determinati browser.

7. Generazione di URL arbitrari (CVE-2012-4520)

Versioni 1.3.x precedenti alla 1.3.4 e 1.4.x precedenti alla 1.4.2

In queste versioni, la funzione django.http.HttpRequest.get_host consente agli aggressori remoti di generare e visualizzare URL arbitrari tramite i valori di intestazione Host di nome utente e password predisposti.

6. CSRF: Richieste contraffatte non autenticate (CVE-2011-4140)»

Versioni successive alla 1.2.7 e dalla 1.3.x alla 1.3.1

CSRF è l'abbreviazione di Cross Site Request Forgery, un attacco che utilizza il browser Web dell'utente per eseguire un'azione indesiderata su un altro sito Web in cui l'utente è attualmente connesso. Il meccanismo di protezione CSRF in queste versioni di Django non gestisce correttamente le configurazioni del server Web che supportano intestazioni host HTTP arbitrarie, consentendo agli aggressori remoti di attivare richieste contraffatte non autenticate tramite vettori che coinvolgono un record CNAME DNS e una pagina Web contenente codice JavaScript.

5. CSRF tramite richieste AJAX contraffatte (CVE-2011-0696)

Versioni 1.1.x precedenti alla 1.1.4 e 1.2.x precedenti alla 1.2.5

Queste versioni di Django non convalidano correttamente le richieste HTTP che contengono un'intestazione X-Requested-With, rendendo banale per gli aggressori remoti eseguire attacchi CSRF (Cross-Site Request Forgery) tramite richieste AJAX contraffatte che sfruttano una "combinazione di plug-in del browser e reindirizzamenti", un problema correlato a CVE-2011-0447.

4. Attraversamento della directory (CVE-2011-0698)

Versioni 1.1.x precedenti alla 1.1.4 e 1.2.x precedenti alla 1.2.5 su Windows

In queste versioni di Django, gli aggressori remoti sono in grado di leggere o eseguire file tramite un carattere/(barra) in una chiave in un cookie di sessione, relativo ai replay della sessione.

3. DoS: tramite vettori non specificati (CVE-2015-5145)

Versioni 1.8.x precedenti alla 1.8.3

DoS è l'abbreviazione di Denial of Service e si verifica quando un utente malintenzionato mette fuori uso una rete/sito Web inondandola di pacchetti di dati. I validatori. URLValidator in queste versioni di Django consente agli aggressori remoti di causare un denial of service (consumo di CPU) tramite vettori non specificati.

2. DoS: tramite richieste multiple con chiavi di sessione univoche (CVE-2015-5143)

Versioni precedenti alla 1.4.21, dalla 1.5.x alla 1.6.x, 1.7.x prima della 1.7.9 e 1.8.x prima della 1.8.3

I backend di sessione in Django consentono agli aggressori remoti di causare un denial of service (consumo dell'archivio di sessione) tramite più richieste con chiavi di sessione univoche.

1. Vulnerabilità legata alla conversione dei tipi (CVE-2014-0474)

Versioni precedenti alla 1.4.11, 1.5.x prima della 1.5.6, 1.6.x prima della 1.6.3 e 1.7.x prima della 1.7 beta

In queste versioni di Django, le seguenti classi di campo non eseguono correttamente la conversione dei tipi:

FilePathField
CampoIndirizzoIPGenerico
CampoIndirizzoIP

Ciò consente agli aggressori remoti di accedere a impatti e vettori non specificati relativi a MySQL.

Bonifica

Per correggere le vulnerabilità di cui sopra, dovrai aggiornare l'attuale versione funzionante del tuo framework Django in tutti i tuoi ambienti. E sebbene Django sia compatibile con le versioni precedenti, è comunque fondamentale identificare tutti i componenti della tua app Web che potrebbero essere interessati da patch/aggiornamento.

UpGuard ti offre un modo per farlo facilmente e automaticamente con pochi clic del mouse. Il nostro potente motore di policy è in grado di convalidare configurazioni sicure per tutti gli ambienti, le infrastrutture e gli stack di applicazioni. In questo caso, è possibile eseguire una semplice policy di sicurezza Django per verificare la presenza di una qualsiasi delle vulnerabilità di cui sopra, nonché di nuove vulnerabilità non ancora aggiunte alla policy. La nostra suite di rilevamento e monitoraggio delle vulnerabilità supportata da OVAL garantisce che tutti i componenti Django siano privi di vulnerabilità e lacune di sicurezza.