Bienvenido a Django 1.1.4!
Esta es la cuarta versión «de corrección de errores» en la serie Django 1.1, que mejora la estabilidad y el rendimiento del código base de Django 1.1.
Con una excepción, Django 1.1.4 mantiene compatibilidad hacia atrás con Django 1.1.3. También contiene un número de correcciones y mejoras. Se recomienda actualizar a Django 1.1.4 para cualquier desarrollo o implementación actualmente utilizando o que se dirija a Django 1.1.
Para obtener detalles completos sobre las nuevas características, incompatibilidades hacia atrás y características obsoletas en la rama 1.1, consulte el Notas de lanzamiento de Django 1.1.
Django incluye un mecanismo de protección contra ataques CSRF, que utiliza un token insertado en las formas salientes. El middleware luego verifica la presencia del token y lo valida al enviar la forma.
Antes de Django 1.2.5, nuestra protección CSRF hacía una excepción para solicitudes AJAX, con la siguiente base:
Muchas herramientas de AJAX agregan un encabezado X-Requested-With cuando se utiliza XMLHttpRequest.
Los navegadores tienen políticas de origen estrictas en cuanto a XMLHttpRequest.
En el contexto de un navegador, la única forma en que se puede agregar una cabecera personalizada de esta naturaleza es con XMLHttpRequest.
Por lo tanto, para facilitar su uso, no aplicamos comprobaciones CSRF a las solicitudes que parecían ser AJAX en función de la cabecera X-Requested-With. El framework web Ruby on Rails tenía una exención similar.
Recientemente, ingenieros de Google informaron a los miembros del equipo de desarrollo de Ruby on Rails sobre una combinación de complementos de navegador y redirecciones que pueden permitir a un atacante proporcionar cabeceras HTTP personalizadas en una solicitud a cualquier sitio web. Esto puede permitir que una solicitud falsificada aparezca como una solicitud AJAX, lo que vuelve inútil la protección CSRF que confía en la naturaleza de origen del mismo origen de las solicitudes AJAX.
Michael Koziarski del equipo de Rails les llamó la atención a esto y pudimos producir un ejemplo de concepto demostrando la misma vulnerabilidad en el manejo de CSRF de Django.
Para remediar esto, Django ahora aplicará comprobaciones CSRF completas a todas las solicitudes, sin importar el origen AJAX aparente. Esto es técnicamente incompatibilidad hacia atrás, pero los riesgos de seguridad se han juzgado superiores a las preocupaciones de compatibilidad en este caso.
Además, Django ahora aceptará el token CSRF en la cabecera HTTP personalizada X-CSRFTOKEN, así como en la presentación del formulario en sí mismo, para facilitar su uso con los conjuntos de herramientas JavaScript populares que permiten la inserción de cabeceras personalizadas en todas las solicitudes AJAX.
Por favor, consulte el docs de CSRF para ejemplo de código jQuery que demuestra esta técnica, asegurándose de que esté mirando la documentación para su versión de Django, ya que el código exacto necesario es diferente para algunas versiones antiguas de Django.
may 31, 2026