Сегодня команда Django выпустила несколько релизов -- Django 1.4.6, Django 1.5.2 и Django 1.6 beta 2 -- для решения проблем с безопасностью. Эти релизы доступны на PyPI и на нашей странице скачивания.
Эти релизы вызваны двумя XSS уязвимостями: одна в виджете, используемом интерфейсом администратора, вторая во вспомогательной функции, которая проверяет перенаправления, которая часто используется после логина или логаута.
Так как эти релизы решают частные проблемы и могут не затрагивать всех пользователей Django, мы рекомендуем всем пользователям оценить риски и обновиться по мере возможности.
Подробности далее.
Проблема: XSS в админке
Админка Django, django.contrib.admin, позволяет легко реализовать CRUD (Creation, Retrieval, Updating and Deleting) функционал для администраторов сайта. Отображая значение поля URLField -- поле модели для хранения URL-ов -- предполагается, что значение проверено и безопасно. Нам предоставили реализацию Django проекта, в котором показано как это можно использовать для XSS атаки в админке.
В простом проекте Django атаке подвержен только интерфейс администратора, т.к. он использует виджет для поля формы из django.contrib.admin. Однако в вашем проекте может быть приложение, которое также использует этот виджет.
Для исправления проблемы был изменен упомянутый виджет -- django.contrib.admin.widgets.AdminURLFieldWidget -- теперь значение поля обрабатывается как и все введённые пользователями значения, оно считается небезопасным и все небезопасные символы будут экранированы.
Спасибо Łukasz Langa за выявление проблемы.
Проблема: Возможный XSS через is_safe_url
Обычным поведением представлений в Django приложениях является получение URL, через параметр запроса, который будет использоваться в случае успешного завершения работы представления. Такое поведение используется в коде Django, например, в представлении логина в django.contrib.auth.views, которое принимает такой параметр, чтобы перенаправить пользователя после успешной авторизации.
Вспомогательная функция -- django.utils.http.is_safe_url() -- предоставляется и используется для проверки, что такой URL находится на текущем хосте (неважно, полный URL или относительный), это позволяет избежать потенциально опасные перенаправления через специально созданные запросы.
Функция is_safe_url() работает как ожидается для HTTP и HTTPS URL, но из-за особенностей парсинга этого URL разрешает перенаправления по другим схемам, например, javascript:. Хотя пока не было реальных примеров XSS атаки через этот механизм, но сама её возможность заставляет нас выпустить этот релиз.
Для решения этой проблемы, функция is_safe_url() была модифицирована для правильного распознования и отклонения URL, которые не пренадлежат схемам HTTP или HTTPS.
Спасибо Nick Bruun за выявление проблемы.
Подверженные версии
Уязвимость URLField XSS присутствует в следующих версиях Django:
- Django 1.5
- Django 1.6 (бета версия)
- Django из основной ветки разработки
Уязвимость в is_safe_url() присутствует в следующих версиях Django:
- Django 1.4
- Django 1.5
- Django 1.6 (бета версия)
- Django из основной ветки разработки
Решение
Патчи были наложены на основную ветку разработки Django, а также на релизные ветки 1.6, 1.5 и 1.4. Патчи доступны напрямую:
Основная ветка разработки:
Ветка Django 1.6:
Ветка Django 1.5:
Ветка Django 1.4:
Выпущены следующие релизы:
- Django 1.6 beta 2 (скачать Django 1.6b2 | 1.6b2 checksums)
- Django 1.5.2 (скачать Django 1.5.2 | 1.5.2 checksums)
- Django 1.4.6 (скачать Django 1.4.6 | 1.4.6 checksums)
Важные замечания относительно уведомлений о проблемах с безопасностью
Как всегда, мы просим, чтобы информация о потенциальных проблемах с безопасностью передавалась через электронную почту на адрес security@djangoproject.com, а не через систему багтрекинга Django или рассылку разработчиков. Пожалуйста, ознакомьтесь с нашей политикой безопасности для дополнительной информации.
1 комментарий | Оставьте комментарий
Мы обновились...