diff options
Diffstat (limited to 'security/vuxml/vuln.xml')
| -rw-r--r-- | security/vuxml/vuln.xml | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/security/vuxml/vuln.xml b/security/vuxml/vuln.xml index f7b879be0830..c74b067aa0f6 100644 --- a/security/vuxml/vuln.xml +++ b/security/vuxml/vuln.xml @@ -51,6 +51,69 @@ Note: Please add new entries to the beginning of this file. --> <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1"> + <vuln vid="5f326d75-1db9-11e2-bc8f-d0df9acfd7e5"> + <topic>django -- multiple vulnerabilities</topic> + <affects> + <package> + <name>django</name> + <range><lt>1.4.2</lt></range> + </package> + <package> + <name>django13</name> + <range><lt>1.3.4</lt></range> + </package> + </affects> + <description> + <body xmlns="http://www.w3.org/1999/xhtml"> + <p>The Django Project reports:</p> + <blockquote cite="https://www.djangoproject.com/weblog/2012/oct/17/security/"> + <ol> + <li> + <p>Host header poisoning</p> + <p>Some parts of Django -- independent of end-user-written applications + -- make use of full URLs, including domain name, which are generated + from the HTTP Host header. Some attacks against this are beyond Django's + ability to control, and require the web server to be properly configured; + Django's documentation has for some time contained notes advising users + on such configuration.</p> + <p>Django's own built-in parsing of the Host header is, however, still + vulnerable, as was reported to us recently. The Host header parsing + in Django 1.3 and Django 1.4 -- specifically, django.http.HttpRequest.get_host() + -- was incorrectly handling username/password information in the header. + Thus, for example, the following Host header would be accepted by Django when + running on "validsite.com":</p> + <p>Host: validsite.com:random@evilsite.com</p> + <p>Using this, an attacker can cause parts of Django -- particularly the + password-reset mechanism -- to generate and display arbitrary URLs to users.</p> + <p>To remedy this, the parsing in HttpRequest.get_host() is being modified; Host + headers which contain potentially dangerous content (such as username/password + pairs) now raise the exception django.core.exceptions.SuspiciousOperation.</p> + </li> + <li> + <p>Documentation of HttpOnly cookie option</p> + <p>As of Django 1.4, session cookies are always sent with the HttpOnly flag, which + provides some additional protection from cross-site scripting attacks by denying + client-side scripts access to the session cookie.</p> + <p>Though not directly a security issue in Django, it has been reported that the + Django 1.4 documentation incorrectly described this change, by claiming that this + was now the default for all cookies set by the HttpResponse.set_cookie() method.</p> + <p>The Django documentation has been updated to reflect that this only applies to the + session cookie. Users of Django are encouraged to review their use of set_cookie() + to ensure that the HttpOnly flag is being set or unset appropriately.</p> + </li> + </ol> + </blockquote> + </body> + </description> + <references> + <url>https://www.djangoproject.com/weblog/2012/oct/17/security/</url> + </references> + <dates> + <discovery>2012-10-17</discovery> + <entry>2012-10-24</entry> + </dates> + </vuln> + <vuln vid="a7706414-1be7-11e2-9aad-902b343deec9"> <topic>Wireshark -- Multiple Vulnerabilities</topic> <affects> |