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

8 февраля 2011 года команда разработчиков Django выпустила два релиза: 1.2.5 и 1.1.4 — лекарство для трёх уведомлений о проблемах с безопасностью.

Изъян в обработке CSRF

Django обладает механизмом защиты от CSRF, который использует специальные метки в отображаемых формах. Механизм прослойки (middleware) проверяет наличие этих меток в отправляемых формах и осуществляет их проверку.

Тем не менее, ранее, наша CSRF защита делала исключение для AJAX запросов на следующей основе:

Множество AJAX библиотек добавляют заголовок X-Requested-With при использовании XMLHttpRequest.
Браузеры обладают жёсткими политиками в отношении XMLHttpRequest.
В контексте браузера такой заголовок может быть определён только при использовании XMLHttpRequest.

Следовательно, для простоты использования, мы не применяли CSRF проверки к запросам, которые выглядели как AJAX запросы (т.е. имели заголовой X-Requested-With). Фреймворк Ruby on Rails работает аналогично.

Недавно инженеры Google указали команде Ruby on Rails на комбинацию браузерных плагинов и перенаправлений, которые могут позволить атакующему назначать любые заголовки запросам к любым сайтам. Это может позволить фальшивым запросам маскироваться под AJAX запросы, разрушая CSRF защиту.

Michael Koziarski из команды Ruby on Rails привлёк наше внимание к этой проблеме и мы смогли воспроизвести подобную уязвимость в обработке CSRF Django.

Чтобы избежать подобного Django теперь применяет полную CSRF проверку ко всем запросам, независимо от источника. Это с технической стороны исключает обратную совместимость, но безопасность важнее обратной совместимости в данном случае.

К тому же Django теперь принимает метку CSRF в новом HTTP заголовке X-CSRFTOKEN, а также и в форме, для удобства использования с популярными библиотеками JavaScript, которые позволяют вставку собственных заголовков в AJAX запросы.

Приведённый ниже пример, используя jQuery, демонстрирует это: вызов функции ajaxSetup заставляет отправлять в запросе заголовок X-CSRFTOKEN:


$.ajaxSetup({
        beforeSend: function(xhr, settings) {
            if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
                // Only send the token to relative URLs i.e. locally.
                xhr.setRequestHeader("X-CSRFToken",
                                     $("#csrfmiddlewaretoken").val());
            }
        }
    });

Для информации, анонс команды Ruby on Rails относительно данной проблемы может быть получен здесь.

Потенциальная XSS при обработке поля для загрузки файла

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

Во многих случаях это не приведёт к проблеме, так как бэкэнды файловых хранилищ (стандартный бэкэнд Django в том числе) могут и обеспечивают проверку передаваемых имён файлов. Тем не менее, риск уязвимости реален в других бэкэндах. Поэтому теперь Django автоматически экранирует имена файлов при обработке формы.

Выход из каталога в Windows

Бэкэнд Django для хранения сессий в файлах обеспечивает хранение данных сессии в файле, в качестве имени которого используется сессионный ключ. Этот бэкэнд проверяет, что ключ, переданный в cookie не содержит символов, перечисленных в os.path.sep языка Python. Если такие символы обнаружены, то вызывается исключение.

Как было указано в отчёте Paul McMillan, этого недостаточно в Windows, так как операции с файловой системой там позволяют использовать большее количество символов (os.path.sep для Windows — это символ обратного слэша, но также принимается и прямой слэш). Из-за другого механизма проверки сессии сохраняются вместе с хэшем их содержимого, а хэш проверяется по десереализованному представлению сессии. Это не позволяет автоматически загрузить или выполнить файлы. Тем не менее, благодаря возможности воспроизвести сессию и более серьёзным уязвимостям сейчас бэкэнд сессий будет явно определять список символов, которые могут находиться в ключе сессии. Этот список исключает любые разделители имён файловой системы.