¿Qué hace realmente la variable ALLOWED_HOSTS de Django?

Me costó un poco encontrarlo, pero encontré esto que parece responder a la pregunta:

enlace

  

Problema: envenenamiento del encabezado del host

     

Varios lanzamientos de seguridad anteriores de Django   han intentado solucionar problemas persistentes con el encabezado del host HTTP.   Django contiene código, y algunas funciones incluidas con Django   en sí mismo hace uso de ese código, para construir un   URL basada en la solicitud HTTP entrante. Dependiendo de la configuración,   esto hace uso del encabezado Host, y por lo tanto un atacante que puede causar un   La aplicación Django para responder a encabezados de host arbitrarios puede causar   Django para generar, y mostrar a los usuarios finales, URL en arbitrario   dominios.

     

Las iteraciones anteriores de este problema (ver CVE-2011-4139 y   CVE-2012-4520) se han centrado en reforzar el análisis de Host de Django   encabezados, para eliminar diversos medios por los cuales los atacantes - usando   Técnicas como pares de nombre de usuario / contraseña en su host enviado   encabezado - podría explotar esto.

     

En última instancia, sin embargo, Django solo no puede garantizar que un atacante esté   no se puede enviar, y hacer que Django acepte, encabezados de host arbitrarios.   Asegurando adecuadamente esto en una instancia de Django desplegada adicionalmente   requiere la configuración del servidor web, y tanto la configuración   y el nivel de seguridad alcanzable varía con el servidor que se está utilizando.

     

A la luz de esto, el método get_host () de django.http.HttpRequest   ahora validará el encabezado del Host contra una nueva configuración,   ALLOWED_HOSTS. Esta configuración es una lista de cadenas (de forma predeterminada, una   lista) correspondiente a los valores aceptables para el encabezado, con algunos   Soporte para comodines.

     

Código que no usa get_host (), o configuraciones de Django que pueden   determinar el nombre de host actual sin recurrir a los encabezados HTTP (es decir,   cuando el framework de sitios de Django esté habilitado) no se verá afectado por esto   cambio.

     

Dado que esto es endurecimiento / ajuste de un problema anterior, no lo hace   tener un nuevo número de CVE.

James Kettle proporciona una buena reseña sobre Ataques de encabezado de host HTTP prácticos . Se resumen a continuación con una descripción de la estrategia ALLOWED_HOSTS de Django.

Vulnerabilidades

Vector de restablecimiento de contraseña

La vulnerabilidad del correo electrónico de restablecimiento de contraseña a la que alude la documentación es el resultado de que Django y / o sus aplicaciones utilizan y confían en el valor del Host HTTP, que proporciona el cliente (¿suena como una mala idea?). El valor del Host se copia directamente en los correos electrónicos de restablecimiento de contraseña, lo que proporciona un vector de inyección práctico.

Envenenamiento de caché

La variación del envenenamiento de caché se basa en este comportamiento, y también en las diferencias en la forma en que los servidores y las soluciones de almacenamiento en caché manejan el encabezado HOST.

HTTP_SERVER vs HTTP ['HOST']

Como describe Kettle, debido a RFC2616, es posible que los servidores compatibles usen una discrepancia entre HTTP_SERVER y HTTP ['HOST'] para entregar cadenas de host arbitrarias.

Análisis de host

Al explotar diferentes formatos y usar caracteres especiales, un atacante puede hacer que un Host 'permitido' sea interpretado maliciosamente en diferentes contextos. Esto es nuevamente un error en la aplicación que confiaba en la cadena del Host.

Solución Django

Como las notas de la versión proporcionadas por En resumen, la solución de Django es que el usuario ponga los hosts permitidos directamente en el código del proyecto. Al prohibir cualquier otro host que no coincida con ALLOWED_HOSTS , el vector de inyección se elimina (un enfoque de "lista blanca").

Esto es algo así como una solución torpe, como señala James, pero también es bastante eficaz.

Ten en cuenta

Es posible usar comodines en la configuración de un proyecto, en cuyo caso esta función no ayuda a proteger nada.

Un desarrollador de aplicaciones seguro evitará usar el valor de HTTP Host de cualquier manera significativa.

Referencias

Carlos Bueno, Cache Poisoning (2008)