Примечания к выпуску Django 1.4.14¶
20 августа 2014
Django 1.4.14 исправляет несколько проблем безопасности в версии 1.4.13.
reverse()
может генерировать URL, указывающие на другие хосты¶
В определенных ситуациях обратный URL может генерировать URL, относящиеся к схеме (URL, начинающиеся с двух косых черт), которые могут неожиданно перенаправить пользователя на другой хост. Злоумышленник может воспользоваться этим, например, перенаправляя пользователей на фишинговый сайт, предназначенный для запроса паролей пользователей.
Чтобы исправить это, теперь обратное преобразование URL гарантирует, что ни один URL не начинается с двух косых черт (//), заменяя вторую косую черту на ее аналог в кодировке URL (%2F). Такой подход гарантирует, что семантика останется неизменной, при этом URL будет относиться к домену, а не к схеме.
Отказ в обслуживании при загрузке файлов¶
До этого релиза, в конфигурации по умолчанию загрузка файлов в Django могла ухудшиться до получения огромного количества системных вызовов os.stat()
при загрузке дублирующего имени файла. Поскольку stat()
может вызывать IO, это может привести к огромному, зависящему от данных замедлению, которое медленно ухудшается со временем. В итоге, пользователь, имеющий возможность загружать файлы, может вызвать низкую производительность обработчика загрузки, что в конечном итоге приведет к тому, что он станет очень медленным, просто загружая файлы размером 0 байт. В этот момент даже медленное сетевое соединение и небольшое количество HTTP-запросов - это все, что необходимо, чтобы сделать сайт недоступным.
Мы исправили эту проблему, изменив алгоритм генерации имен файлов, если файл с загруженным именем уже существует. Storage.get_available_name()
теперь добавляет знак подчеркивания плюс случайную 7-символьную буквенно-цифровую строку (например, "_x3a1gho"
), а не итерацию через знак подчеркивания, за которым следует число (например, "_1"
, "_2"
и т.д.).
RemoteUserMiddleware
перехват сеанса¶
При использовании RemoteUserMiddleware
и RemoteUserBackend
изменение заголовка REMOTE_USER
между запросами без промежуточного выхода из системы могло привести к тому, что сессия предыдущего пользователя переходила к последующему. Теперь промежуточное ПО выводит пользователя из системы при неудачной попытке входа.
Утечка данных через манипуляцию строкой запроса в contrib.admin
¶
В старых версиях Django можно было раскрыть данные любого поля, изменив параметры «popup» и «to_field» строки запроса на странице формы изменения администратора. Например, запрос URL вида /admin/auth/user/?pop=1&t=password
и просмотр HTML страницы позволял увидеть хэш пароля каждого пользователя. Хотя администратор требует от пользователей наличия прав доступа для просмотра страниц формы изменения, это может привести к утечке данных, если вы полагаетесь на то, что пользователи имеют доступ к просмотру только определенных полей модели.
Чтобы решить эту проблему, теперь будет возникать исключение, если указано значение to_field
, которое не является связанным полем модели, зарегистрированной в администраторе.