Security Release

Выпущено обновление Django, решающее проблемы с безопасностью

30 июля 2012 команда разработчиков Django выпустила релизы 1.3.2 и 1.4.1, которые закрывают проблемы с безопасностью.

Всем пользователям рекомендуется выполнить немедленное обновление Django.

Кроссайтовый скриптинг в представлениях аутентификации

Представления login() и logout() модуля аутентификации Django используют стандартное поведение "POST-перенаправление-GET", т.е. позволяют указывать точку перенаправления в параметрах запроса. В настоящее время, эти представления выполняют простую проверку на то, что перенаправление использует тот же домен.

Тем не менее, данная проверка не принимает во внимание схему целевого URL. Вооружившись этим знанием, атакующий может воспользоваться к примеру схемой data:, что приведёт к выполнению JavaScript на целевом браузере.

Некоторые браузеры уже сейчас предоставляют защиту от такой атаки: Google Chrome не позволяет использовать схему data: для перенаправлений. Но большая часть браузеров не учитывает этот аспект.

После тщательного рассмотрения данной проблемы мы решили, что немного пожертвовать обратной совместимостью ради безопасности. Несмотря на то, что временное решение могло быть достигнуто посредством более строгой проверки в соответствующих представлениях, основная проблема находится в классах ответа HTTP, которые вообще не выполняют никаких проверок. Тот факт, что некоторые браузеры уже запрещают использование для перенаправления определённые схемы URL указывает на несущественный объём действий, который придётся сделать в результате наших изменений.

Итак, были выполнены следующие изменения, которые нарушили обратную совместимость:

• Классы django.http.HttpResponseRedirect и django.http.HttpResponsePermanentRedirect теперь наследуются от общего базового класса django.http.HttpResponseRedirectBase.
• Этот базовый класс определяет явный список разрешённых схем URL. Попытки создания перенаправления с схемой URL, не входящей в данный список, будут приводить к вызовы исключения django.core.exceptions.SuspiciousOperation, которое уже реализовано для аналогичных целей в других частях кода Django (например, для уведомления о попытке модификации сессии).

Код конечного пользователя, отвечающий за перенаправления, будет работать без проблем, если только он явно не использует схемы URL, отсутствующие в белом списке, или разрешает пользователям измененять схему URL.

Для последнего случая потребуется создать соответствующий класс перенаправления, наследуясь от HttpResponseRedirect (для кода состояния 302) или HttpResponsePermanentRedirect (для кода состояния 301), и переопределить в нём список allowed_schemes. По умолчанию, этот список содержит: ['http', 'https', 'ftp'].

Для первого случая, код, позволяющий пользователю указывать схему URL, может попытаться создать экземпляр класса перенаправления, поймать исключение SuspiciousOperation и выполнить переход по другому URL.

В настоящее время представления модуля аутентификации Django не ловят данное исключение. Это означает, что администраторы сайтов получат сообщения об ошибке, если данное исключение будет вызвано. Скорее всего следующие версии Django будут ловить это исключение, позволяя пользователям исследовать поведение и решать, что с ним делать.

Отказ сервиса через get_image_dimensions()

Django предоставляет вспомогательные методы для работы с изображениями, такие как методы определения разрешения изображения. Сейчас, для этого происходит чтение 1024 байтного блока от начала файла, его передача PIL для определения разрешения. При необходимости читается ещё 1024 байта, и ещё, и так до получения от PIL вменяемого ответа.

Такой подход отлично работает с изображениями, чей формат содержит достаточную информацию в заголовке. Для остальных изображений это может вылится в достаточно большое количество циклов чтения/обработки. К примеру, большие TIFF изображения требуют десятки тысяч таких циклов, занимая значительные ресурсы, что может привести к отказу сервиса.

Для решения этой проблемы был изменён алгоритм определения разрешения изображений. Первая попытка по-прежнему читает 1024 байтовый блок, но размер следующего блока каждый раз удваивается. Тестирование показало, что такой подход уменьшает время обработки TIFF изображений.

Версии, которые надо обновить

Описанные проблемы касаются следующих версий Django:

• Django Development;
• Django 1.4;
• Django 1.3.

Решение

На код Django были наложены патчи, во все указанные выше ветки. Каждый патч можно посмотреть:

• Django Development: коммит для перенаправлений, коммит для проверки изображений и коммит для получения размера изображений;
• Django 1.4: коммит для перенаправлений, коммит для проверки изображений и коммит для получения размера изображений;
• Django 1.3: коммит для перенаправлений, коммит для проверки изображений и коммит для получения размера изображений.

Выпущены следующие релизы:

• Django 1.4.1 (скачать | контрольная сумма)
• Django 1.3.2 (скачать | контрольная сумма)

Так как ветка разработки Django находится в pre-alpha состоянии, не рекомендуется использовать этот код на боевых серверах. Если же вы это всё-таки делаете, то немедленно следует обновиться до текущего HEAD, который содержит описанные патчи.

Благодарности

Проблема определения размера изображения была описана Jeroen Dekkers. Проблема проверки изображения была описана в багтрекере. Проблема с перенаправлением была описана анонимным источником.

Состояние проблем

Команде Django была предоставлена информация, которая указывает, что знание о проблеме с перенаправлением распространяется и может быть вскоре использовано для атак. Как было указано ранее, информация о проблеме с определением размера изображения была указана через багтрекер.

Рекомендуем выполнить немедленное обновление.

Исходное сообщение на djangoproject.com