Cosa fa in realtà la variabile ALLOWED_HOSTS di Django?

Mi ci è voluto un po 'di scavo per trovarlo, ma ho trovato questo che sembra rispondere alla domanda:

link

Issue: Host header poisoning

Several previous Django security releases have attempted to address persistent issues with the HTTP Host header. Django contains code -- and some functionality shipped with Django itself makes use of that code -- for constructing a fully-qualified URL based on the incoming HTTP request. Depending on configuration, this makes use of the Host header, and so an attacker who can cause a Django application to respond to arbitrary Host headers can cause Django to generate, and display to end users, URLs on arbitrary domains.

Previous iterations of this issue (see CVE-2011-4139 and CVE-2012-4520) have focused on tightening Django's parsing of Host headers, to eliminate various means by which attackers -- using techniques such as username/password pairs in their submitted Host header -- could exploit this.

Ultimately, however, Django alone cannot ensure that an attacker is unable to submit, and cause Django to accept, arbitrary Host headers. Properly securing this in a deployed Django instance additionally requires configuration of the web server, and both the configuration and the achievable level of security vary with the server being used.

In light of this, the get_host() method of django.http.HttpRequest will now validate the Host header against a new setting, ALLOWED_HOSTS. This setting is a list of strings (by default, an empty list) corresponding to acceptable values for the header, with some support for wildcards.

Code which does not use get_host(), or Django configurations which can determine the current hostname without recourse to HTTP headers (i.e., when Django's sites framework is enabled) will not be affected by this change.

Since this is hardening/tightening of a previous issue, it does not have a new CVE number.

James Kettle fornisce una buona scrittura su Pratici attacchi HTTP Host Header . Sono riassunti qui con una descrizione della strategia di Django ALLOWED_HOSTS.

Vulnerabilità

Vettore di reimpostazione della password

La vulnerabilità della posta elettronica di reimpostazione della password a cui la documentazione allude è il risultato di Django e / o delle sue applicazioni che utilizzano e si fidano del valore dell'host HTTP, fornito dal client (sembra una cattiva idea?). Il valore dell'host viene copiato direttamente nelle e-mail di reimpostazione della password, fornendo un utile vettore di iniezione.

Avvelenamento da cache

La variazione dell'avvelenamento della cache si basa su questo comportamento e anche sulle differenze nel modo in cui l'intestazione HOST viene gestita dai server e dalle soluzioni di memorizzazione nella cache.

HTTP_SERVER vs HTTP ['HOST']

Come descrive Kettle, a causa di RFC2616, è possibile con server compatibili utilizzare una discrepanza tra HTTP_SERVER e HTTP ['HOST'] per fornire stringhe host arbitrarie.

Analisi host

Sfruttando diversi formati e utilizzando caratteri speciali, un utente malintenzionato può causare l'interpretazione di un host "consentito" malevolo in diversi contesti. Questo è di nuovo un errore nell'applicazione che si è fidata della stringa Host.

Soluzione Django

Poiché le note di rilascio fornite da Riassumendo Catskul, la soluzione Django consiste nel fare in modo che l'utente inserisca gli host consentiti direttamente nel codice del progetto. Proibendo qualsiasi altro host che non corrisponde a ALLOWED_HOSTS , il vettore di iniezione viene eliminato (un approccio "elenco bianco").

Questa è una soluzione goffo, come sottolinea James, ma è anche piuttosto efficace.

Tieni presente

È possibile utilizzare i caratteri jolly nelle impostazioni di un progetto, nel qual caso questa funzione non aiuta a proteggere nulla.

Uno sviluppatore di applicazioni sicuro eviterà di utilizzare il valore dell'host HTTP in modo significativo.

Riferimenti

Carlos Bueno, Cache Poisoning (2008)