Релиз Django 1.2.2 — security-обновление

    8 сентября 2010 года разработчики Django выпустили релиз 1.2.2 чтобы закрыть уязвимости, позволяющие злоумышленникам устраивать XSS-атаки. По злой иронии, уязвимость к XSS оказалась в коде системы, выполняющем защиту от другого типа атак – CSRF. Система эта принципиально изменилась в версии 1.2 (в предыдущих версиях защита от CSRF не являлась частью ядра фреймворка и была всего лишь подключаемым слоем).

    Суть

    Защита от CSRF работает по следующему принципу: генерируется случайная последовательность (токен), которая вставляется в hidden-поле формы и та же последовательность записывается в специальную cookie. При отправке формы значения скрытого поля и cookie сравниваются и, если эти значения совпали, считается, что форма была заполнена достоверным пользователем.

    Теперь собственно об уязвимости: как оказалось, шаблонный тег {% csrf_token %}, используемый для вставки HTML-кода скрытого поля в код формы, безоговорочно доверяет значению токена и вставляет его, не экранируя. Значение же токена берётся из cookie. Таким образом, атакующий потенциально может подделать cookie и внедрить в его значение HTML-код, внедрив его тем самым на страницу.

    Уязвимые версии

    • Текущая trunk-версия
    • Django 1.2.x
    Версии до 1.2 не подвержены узявимости.

    Решение проблемы

    Разработчики предлагают всем пользователям ветки 1.2 немедленно обновиться до 1.2.2 и отмечают, что они не делали предварительных уведомлений.

    Можно вручную применить патч или посмотреть diff, чтобы лучше понять суть уязвимости.

    См. также


    P.S. странно, что за почти сутки на новость не обратили особого внимания, хотя некоторые среагировали оперативно
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 16

    • UFO just landed and posted this here
        0
        Судя по кол-ву тикетов на 1.3 до 2.0 там еще очень далеко
          +6
          И так сделано достаточно много и хорошо. Чего вы ждёте от второй версии?
          • UFO just landed and posted this here
          0
          «позволяющие злоумышленникам устраивать XSS-атаки»
          кто-нибудь сможет привести пример, когда модификация своей куки позволит провести атаку на кого-нибудь, кроме себя?
            0
            Какой-нибудь злой скрипт на стороне пользователя может отправить такую куку на сервер. Таким образом, пользователь получит злой код уже не от злого скрипта, а от благонадёжного сервера.

            Хотя я не знаю, насколько реалистична такая угроза, но суть данной новости в том, что дыры надо закрывать, даже если они не критические. Комбинация нескольких некритических дыр может создать критическую уязвимость.
              0
              Правильно, но он получит скрипт только в случае, если у него кука модифицирована. Если у злоумышленника дотянулись руки до пользовательских кук — то уже всё что можно на клиенте доступно и так.
                +1
                Как мне видится возможный сценарий:
                — как-то внедрили скрипт, модифицирующий куку на страницу, например, товара (публичная торговая площадка, скажем, не без экранирования описания товара) — там сам по себе он никаких пользовательских данных собрать не может, лишь потому, что их там нет
                — при переходе на страницу с формой оплаты изменяем action на свой и получаем, например, данные кредитки
                  0
                  Да, понял. Спасибо.
                  • UFO just landed and posted this here
                      0
                      Для эксплуатации многих дыр слишком много «если», например получили с помощью SQL Injection доступ к БД, а пароли там зашифрованные :)
                      • UFO just landed and posted this here
                          0
                          Есть достаточно много ресурсов, где вся информация и так в паблике, конфиденциальным является только пароль :)
              +2
              Наверное, скоро 1.2.3 выйдет, там пара багов в 1.2.2.
              0
              Патч откатили и переделали: code.djangoproject.com/changeset/13733

              Only users with full accounts can post comments. Log in, please.