mirror of
https://github.com/django/django.git
synced 2024-12-24 18:16:19 +00:00
69 lines
3.0 KiB
Plaintext
69 lines
3.0 KiB
Plaintext
===========================
|
|
Django 1.10.3 release notes
|
|
===========================
|
|
|
|
*November 1, 2016*
|
|
|
|
Django 1.10.3 fixes two security issues and several bugs in 1.10.2.
|
|
|
|
User with hardcoded password created when running tests on Oracle
|
|
=================================================================
|
|
|
|
When running tests with an Oracle database, Django creates a temporary database
|
|
user. In older versions, if a password isn't manually specified in the database
|
|
settings ``TEST`` dictionary, a hardcoded password is used. This could allow
|
|
an attacker with network access to the database server to connect.
|
|
|
|
This user is usually dropped after the test suite completes, but not when using
|
|
the ``manage.py test --keepdb`` option or if the user has an active session
|
|
(such as an attacker's connection).
|
|
|
|
A randomly generated password is now used for each test run.
|
|
|
|
DNS rebinding vulnerability when ``DEBUG=True``
|
|
===============================================
|
|
|
|
Older versions of Django don't validate the ``Host`` header against
|
|
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
|
|
vulnerable to a `DNS rebinding attack
|
|
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
|
|
|
|
While Django doesn't ship a module that allows remote code execution, this is
|
|
at least a cross-site scripting vector, which could be quite serious if
|
|
developers load a copy of the production database in development or connect to
|
|
some production services for which there's no development instance, for
|
|
example. If a project uses a package like the ``django-debug-toolbar``, then
|
|
the attacker could execute arbitrary SQL, which could be especially bad if the
|
|
developers connect to the database with a superuser account.
|
|
|
|
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
|
|
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
|
|
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
|
|
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
|
|
now omit it to get those fallback values.
|
|
|
|
Bugfixes
|
|
========
|
|
|
|
* Allowed ``User.is_authenticated`` and ``User.is_anonymous`` properties to be
|
|
tested for ``set`` membership (:ticket:`27309`).
|
|
|
|
* Fixed a performance regression when running ``migrate`` in projects
|
|
with ``RenameModel`` operations (:ticket:`27279`).
|
|
|
|
* Added ``model_name`` to the ``allow_migrate()`` calls in ``makemigrations``
|
|
(:ticket:`27200`).
|
|
|
|
* Made the ``JavaScriptCatalog`` view respect the ``packages`` argument;
|
|
previously it was ignored (:ticket:`27374`).
|
|
|
|
* Fixed ``QuerySet.bulk_create()`` on PostgreSQL when the number of objects is
|
|
a multiple plus one of ``batch_size`` (:ticket:`27385`).
|
|
|
|
* Prevented ``i18n_patterns()`` from using too much of the URL as the language
|
|
to fix a use case for ``prefix_default_language=False`` (:ticket:`27063`).
|
|
|
|
* Replaced a possibly incorrect redirect from ``SessionMiddleware`` when a
|
|
session is destroyed in a concurrent request with a ``SuspiciousOperation``
|
|
to indicate that the request can't be completed (:ticket:`27363`).
|