FreshPorts - VuXML

Django team reports:

These release addresses two security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

• Open redirect and possible XSS attack via user-supplied numeric redirect URLs
• Open redirect vulnerability in django.views.static.serve()

< 1.8.18

< 1.8.18

< 1.9.13

< 1.10.7

Tim Graham reports:

Malicious redirect and possible XSS attack via user-supplied redirect URLs containing basic auth

User enumeration through timing difference on password hasher work factor upgrade

< 1.8.10

< 1.8.10

< 1.9.3

le 20150709,1

The Django project reports:

Today the Django team released Django 1.10.3, Django 1.9.11, and 1.8.16. These releases addresses two security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

• User with hardcoded password created when running tests on Oracle
• DNS rebinding vulnerability when DEBUG=True

< 1.8.16

< 1.8.16

< 1.9.11

< 1.10.3

Tim Graham reports:

If an application allows users to specify an unvalidated format for dates and passes this format to the date filter, e.g. {{ last_updated|date:user_date_format }}, then a malicious user could obtain any secret in the application's settings by specifying a settings key instead of a date format. e.g. "SECRET_KEY" instead of "j/m/Y".

< 1.8.7

< 1.8.7

< 1.7.11

le 20150709,1

Tim Graham reports:

Denial-of-service possibility in logout() view by filling session store

Previously, a session could be created when anonymously accessing the django.contrib.auth.views.logout view (provided it wasn't decorated with django.contrib.auth.decorators.login_required as done in the admin). This could allow an attacker to easily create many new session records by sending repeated requests, potentially filling up the session store or causing other users' session records to be evicted.

The django.contrib.sessions.middleware.SessionMiddleware has been modified to no longer create empty session records.

This portion of the fix has been assigned CVE-2015-5963.

Additionally, on the 1.4 and 1.7 series only, the contrib.sessions.backends.base.SessionBase.flush() and cache_db.SessionStore.flush() methods have been modified to avoid creating a new empty session. Maintainers of third-party session backends should check if the same vulnerability is present in their backend and correct it if so.

This portion of the fix has been assigned CVE-2015-5964. Anyone reporting a similar vulnerability in a third-party session backend should not use this CVE ID.

Thanks Lin Hua Cheng for reporting the issue.

< 1.8.4

< 1.7.10

< 1.4.22

le 20150709,1

The Django Project reports:

These security releases fix four issues: one potential phishing vector, one denial-of-service vector, an information leakage issue, and a range of XML vulnerabilities.

1. Host header poisoning

   an attacker could cause Django to generate and display URLs that link to arbitrary domains. This could be used as part of a phishing attack. These releases fix this problem by introducing a new setting, ALLOWED_HOSTS, which specifies a whitelist of domains your site is known to respond to.

   Important: by default Django 1.3.6 and 1.4.4 set ALLOWED_HOSTS to allow all hosts. This means that to actually fix the security vulnerability you should define this setting yourself immediately after upgrading.

2. Formset denial-of-service

   an attacker can abuse Django's tracking of the number of forms in a formset to cause a denial-of-service attack. This has been fixed by adding a default maximum number of forms of 1,000. You can still manually specify a bigger max_num, if you wish, but 1,000 should be enough for anyone.

3. XML attacks

   Django's serialization framework was vulnerable to attacks via XML entity expansion and external references; this is now fixed. However, if you're parsing arbitrary XML in other parts of your application, we recommend you look into the defusedxml Python packages which remedy this anywhere you parse XML, not just via Django's serialization framework.

4. Data leakage via admin history log

   Django's admin interface could expose supposedly-hidden information via its history log. This has been fixed.

ge 1.3 lt 1.3.6

ge 1.4 lt 1.4.4