Django 1.4.14 版本发行说明
Django 1.4.14 fixes several security issues in 1.4.13.
In certain situations, URL reversing could generate scheme-relative URLs (URLs starting with two slashes), which could unexpectedly redirect a user to a different host. An attacker could exploit this, for example, by redirecting users to a phishing site designed to ask for user’s passwords.
Before this release, Django’s file upload handing in its default configuration may degrade to producing a huge number of os.stat()
system calls when a duplicate filename is uploaded. Since may invoke IO, this may produce a huge data-dependent slowdown that slowly worsens over time. The net result is that given enough time, a user with the ability to upload files can cause poor performance in the upload handler, eventually causing it to become very slow simply by uploading 0-byte files. At this point, even a slow network connection and few HTTP requests would be all that is necessary to make a site unavailable.
We’ve remedied the issue by changing the algorithm for generating file names if a file with the uploaded name already exists. Storage.get_available_name() now appends an underscore plus a random 7 character alphanumeric string (e.g. "_x3a1gho"
), rather than iterating through an underscore followed by a number (e.g. "_1"
, "_2"
, etc.).
In older versions of Django it was possible to reveal any field’s data by modifying the “popup” and “to_field” parameters of the query string on an admin change form page. For example, requesting a URL like /admin/auth/user/?pop=1&t=password
and viewing the page’s HTML allowed viewing the password hash of each user. While the admin requires users to have permissions to view the change form pages in the first place, this could leak data if you rely on users having access to view only certain fields on a model.
To address the issue, an exception will now be raised if a to_field
value that isn’t a related field to a model that has been registered with the admin is specified.