Envenenamiento de cabeceras en Django 1.3 y 1.4

Para realizar algunas operaciones, Django extrae el nombre del dominio de la cabecera «Host» enviada. La vulnerabilidad (CVE-2012-4520) reside en el parser del método django.http.HttpRequest.get_host(), que extrae esta cabecera «Host» incorrectamente.

Una cabecera válida tendría el siguiente formato:

Host: example.com

Si a Django se le proporciona una petición con esta cabecera manipulada, como por ejemplo:

Host: example.com:algo@example2.com

Django extraerá y entenderá que el dominio deseado es «example2.com» en lugar de «example.com«, que es el correcto.

Un caso particular de ataque se produciría en el caso de restablecer la contraseña del usuario. Un atacante podría simular una petición de nueva contraseña con la cabecera Host especialmente manipulada, y que a la víctima le llegase un confirmación (o nueva contraseña) con un texto similar a «Visite http://example2.com/login para…» en lugar de aparecer el dominio legítimo. Si este usuario (que en realidad no ha solicitado nada) picase, introduciría sus datos en otro dominio. Esto ocurriría tanto en con el gestor de usuarios integrado de Django, o con cualquier aplicación de este tipo realizada con Django.http.HttpRequest.get_host.

Además del fallo descrito, se ha actualizado la documentación debido a la incorrecta descripción del método HttpResponse.set_cookie(), que podría facilitar ataques XSS en las webs que implementaran incorrectamente este método. La documentación de Django 1.4, que argumentaba incorrectamente que el método HttpResponse.set_cookie() establecía siempre la propiedad HttpOnly para todas las cookies (propiedad que añade protección adicional ante ataques XSS de scripts maliciosos). Ahora se advierte que sólo lo hace para las cookies de sesión.

Se recomienda actualizar a las versiones correspondientes de cada rama, 1.3.4 o a la 1.4.2.

Django 1.3.4

Django 1.4.2

Antonio Sánchez