Призыв присоединиться к спринту по разработке Django

> Тикеты искать лень, уязвимость была (и есть до сих пор !!!) в коллизии сессий. То есть юзер А имеет вероятность случайно попасть в сессию юзера Б, и не смотря на то, что вероятность этого достаточно мала, такие события случаются на практике.

Ну давай посчитаем. Пусть у тебя в базе 1 миллион, нет, миллиард сессий (10^9). Ключ сессии создаётся так:

session_key = md5.new("%s%s%s%s" % (random.randint(0, sys.maxint - 1), os.getpid(), time.time(), settings.SECRET_ KEY)).hexdigest()

Итак, можно считать его псевдослучайным числом с равномерным распределением от 0 до 2^128 ~ 3 * 10^128. Итого, вероятность коллизии будет порядка 10^9 / 10^128, то есть, 10^111. Если на твой сервер заходит 1000 человек в секунду, то коллизии будут случаться в среднем один раз в 10^100 лет. Возраст вселенной, для сравнения, ты сам знаешь или подсказать? :)

О, виноват, невнимательно посмотрел. Вот весь кусок кода:

def get_new_session_key(self):
    "Returns session key that isn't being used."
    # The random module is seeded when this Apache child is created.
    # Use SECRET_KEY as added salt.
    while 1:
        session_key = md5.new("%s%s%s%s" % (random.randint(0, sys.maxint - 1), os.getpid(), time.time(), settings.SECRET_
KEY)).hexdigest()
        try:
            self.get(session_key=session_key)
        except self.model.DoesNotExist:
            break
    return session_key

Где тут возможность коллизий?

ero-sennin, я не буду с тобой спорить, есть в django-developers соответствующая тема, где все описано. Ты в теории чего-то там считаешь, а у меня на практике было 2 (ДВА) зарегистрированных случая попадания человеком в чужую сессию. И еще х.з. сколько не зарегистрированных.
Коллизия возможна потому, что сначала создается новый session_key, а потом (спустя какое-то время), запись с этим session_key попадает в базу. За это "какое-то" время система может запросто выдать еще один такой же session key другому человеку и на практике это случалось.
Можешь доказывать тут что угодно, но когда у тебя "случайно" юзер Вася получит сессию администратора, смешного будет мало. Мой модуль newsessions эту проблему решал принципиально: пустая сессия еще ДО ее использования писалась в базу, таким образом выдать второй раз тот же session_key просто невозможно.
Сколько еще таких же ляпов в коде django я не знаю

http://groups.google.com/group/django-developers/browse_thread/thread/f456b6b...

> Мой модуль newsessions эту проблему решал принципиально: пустая
сессия еще ДО ее использования писалась в базу, таким образом выдать
второй раз тот же session_key просто невозможно.

Кончаем дуть губки, вылаезаем из танка и идём читать код: =)

def get_new_session_object(self):
    """
    Returns a new session object.
    """
    # FIXME: There is a *small* chance of collision here, meaning we will
    # return an existing object. That can be fixed when we add a way to
    # validate (and guarantee) that non-auto primary keys are unique. For
    # now, we save immediately in order to reduce the "window of
    # misfortune" as much as possible.
    created = False
    while not created:
        obj, created = self.get_or_create(session_key=self.get_new_session_key(),
                expire_date = datetime.datetime.now())
        # Collision in key generation, so re-seed the generator
        random.seed()
        return obj

Этот кусок кода делает то же самое, что и ваш патч, плюс ещё и
перезаряжает генератор случайных чисел, если вдруг случается
коллизия (перечитайте ещё раз посты Сагалаева).

А ваша принципиальная ошибка заключалась в том, что вы одним патчем пытались решать две проблемы. Почитайте /usr/src/linux/HOWTO, если ещё не читали. Если бы вы завели два отдельных тикета, один о коллизиях, другой о привязке к IP, думаю, всё было бы по другому.

И потом, что мешает лично вам использовать newsession вместо django.contrib.session? Для этого не надо ничего форкать.

И потом, тикет вы завелил 13 марта, а 21 марта исправление уже внесли в trunk: http://code.djangoproject.com/changeset/4771. По-моему, вполне оперативно.

А что касается привязки к IP, я тоже думаю, что от неё больше проблем, чем пользы. Как минимум стоило сделать её отдельным патчем и сделать отключаемой и отключенной по умолчанию.

Господа, всё это хорошо, а Model Inheritance там появилось? Или one-to-one relationship наконец дочинили до адекватной работы с админкой? А то задолбало модель User расширять через ForeignKey.

> Кончаем дуть губки, вылаезаем из танка и идём читать код: =)

Вот именно из-за такого подхода я и форкнул django для себя и юзаю собственную версию. Делаешь людям доброе дело, а они тебя вместо "спасибо" еще и нахер посылают.

Кстати, если уж ты любишь смотреть в код, посмотри в комментарий в get_new_session_object(): http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/mo...

> А ваша принципиальная ошибка заключалась в том, что вы одним патчем пытались решать две проблемы

Я вообще не считаю что у меня была какая-то принципиальная ошибка. Я сообщил о проблеме и прислал патч, который ее решает. Всё.

> И потом, что мешает лично вам использовать newsession вместо django.contrib.session? Для этого не надо ничего форкать

Собственно, так и сделал. Если бы это был единственный патч, то ничего бы и не форкал.
_На то время_ у меня был набор патчей, который позволял использовать django в реальных условиях, то есть при работе с MySQL >=4.1 чтобы при этом исходники были в cp1251, чтобы работал newforms и т.п., а trunk-версия при таком наборе условий нифига не работала. Я сделал так, чтобы можно было писать код на newforms и он бы работал сразу, а не через пол года, когда newforms допилят. Вот и всё.
В итоге с прошлой осени по сегодняшний день у нас написана тонна работающего в production кода, а парни из django до сих пор чего-то там еще пилят.
Я _пытался_ им помочь, но понял что им это не нужно.

> Кстати, если уж ты любишь смотреть в код, посмотри в комментарий в get_new_session_object():

Вероятность там теперь и правда _очень_ мала. Особенно после того, как аргументам хэша добавили os.getpid() и time.time(). И я вполне понимаю, почему они не хотят менять модели и ломать обратную совместимость. Но на всякий случай спросил вот здесь: http://code.djangoproject.com/ticket/1180#comment:21.

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

Ну а чтобы у других тоже было понимание обратной стороны медали, я и написал о своем опыте. В любом случае, я ни на кого не обижаюсь :)

Кстати, обрати внимание на дату предыдущего перед твоим сообщения о аналогичной проблеме на http://code.djangoproject.com/ticket/1180
Если код, который фиксит проблему, был добавлен 21 марта, то люди, повторно сообщающие о проблеме 28 августа явно должны пользоваться уже патченым кодом, не так ли ?

> Ы