Page 13 of 79 results (0.005 seconds)

CVSS: 5.8EPSS: 1%CPEs: 22EXPL: 0

django.contrib.sessions in Django before 1.2.7 and 1.3.x before 1.3.1, when session data is stored in the cache, uses the root namespace for both session identifiers and application-data keys, which allows remote attackers to modify a session by triggering use of a key that is equal to that session's identifier. django.contrib.sessions en Django v1.2.7 y v1.3.x antereiores a v1.3.1, cuando los datos de sesión se almacena en la caché, utiliza el espacio de nombres raíz de los identificadores de sesión las teclas y los datos de aplicación, lo que permite a atacantes remotos modificar un sesión mediante la activación de uso de una clave que es igual al identificador de sesión. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •

CVSS: 6.8EPSS: 0%CPEs: 22EXPL: 0

The CSRF protection mechanism in Django through 1.2.7 and 1.3.x through 1.3.1 does not properly handle web-server configurations supporting arbitrary HTTP Host headers, which allows remote attackers to trigger unauthenticated forged requests via vectors involving a DNS CNAME record and a web page containing JavaScript code. El mecanismo de protección ante CSRF de Django hasta la versión 1.2.7 y 1.3.x hasta la 1.3.1 no maneja apropiadamente las configuraciones del servidor web que soportan cabeceras HTTP Host arbitrarias, lo que permite a atacantes remotos provocar peticiones falsificadas sin autenticar a través de vectores que involucran un registro DNS CNAME y una página web que contenga código JavaScript. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-352: Cross-Site Request Forgery (CSRF) •

CVSS: 5.0EPSS: 1%CPEs: 22EXPL: 0

Django before 1.2.7 and 1.3.x before 1.3.1 uses a request's HTTP Host header to construct a full URL in certain circumstances, which allows remote attackers to conduct cache poisoning attacks via a crafted request. Django v1.2.7 y v1.3.x anterior a v1.3.1 usa la cabecera de una petición HTTP host para la construcción de una dirección URL completa, en determinadas circunstancias, lo que permite a atacantes remotos para realizar ataques de envenenamiento de caché a través de una solicitud manipulada. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •

CVSS: 5.0EPSS: 0%CPEs: 22EXPL: 0

The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 originally tests a URL's validity through a HEAD request, but then uses a GET request for the new target URL in the case of a redirect, which might allow remote attackers to trigger arbitrary GET requests with an unintended source IP address via a crafted Location header. La funcionalidad verify_exists de la implementación URLField en Django antes de su versión v1.2.7 y en v1.3.x antes de v1.3.1 originalmente comprueba la validez de una URL a través de una petición HEAD, pero luego usa una petición GET de la URL en el caso de un redireccionamiento. Esto podría permitir a atacantes remotos para provocar peticiones GET aleatorias con una dirección IP de origen no deseados a través de una cabecera Location especificamente modificada. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •

CVSS: 5.0EPSS: 3%CPEs: 22EXPL: 0

The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 relies on Python libraries that attempt access to an arbitrary URL with no timeout, which allows remote attackers to cause a denial of service (resource consumption) via a URL associated with (1) a slow response, (2) a completed TCP connection with no application data sent, or (3) a large amount of application data, a related issue to CVE-2011-1521. La funcionalidad verify_exists de la implementación de URLField en Django en versiones anteriores a 1.2.7 y 1.3.x anteriores a 1.3.1 se basa en librerías Python que tratan de acceder a URLs arbitrarias sin un temporizador, lo que permite a atacantes remotos provocar una denegación de servicio (consumo de todos los recursos) a través de una URL asociada con (1) una respuesta lenta, (2) una conexión TCP completa sin datos enviados o (3) una gran cantidad de datos de aplicación. Un problema relacionado con CVE-2011-1521. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://openwall.com/lists/oss-security/2011/09/15/5 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-399: Resource Management Errors •