Чем грозит отсутствие циклического использования сессионных ключей в Django?
Django зацикливает ключ сессии при входе в систему. Обоснование (которое я не понимаю) приведено в этом pull request:
При входе в систему измените ключ сеанса, сохранив при этом все существующие сессию. Это означает, что пользователь будет видеть свою сессию сохраненной через границу входа в систему. но кто-то, подглядывающий за ключом анонимной сессии, не сможет просмотреть данные аутентифицированной сессии.
Циклирование ключа сессии неудобно, если вы хотите легко связать поведение unauth с позже вошедшим пользователем. В этом ответе предлагается просто отключить cycle_key.
Какие риски существуют при отключении cycle_key? (Связано с комментарием выше или другими)
EDIT: Хорошо, я думаю, что понимаю обоснование выше. Это буквально означает, что если вы пронюхали о действиях unauth, вы не сможете связать их с действиями auth. Я понимаю, как это может быть приятно, но 1) в идеале и действия unauth, и действия auth защищены (например, https), 2) это преимущество безопасности должно быть взвешено с преимуществом сохранения ключа сессии.
Посмотрев на документацию для cycle_key там говорится (выделено мной):
Создает новый ключ сессии, сохраняя данные текущей сессии. django.contrib.auth.login() вызывает этот метод для защиты от фиксации сессии.
Следовательно, причина цикличности ключа сессии заключается в предотвращении атаки фиксации сессии [OWASP]. После некоторых исследований атака фиксации сеанса - это атака, при которой злоумышленник получает идентификатор сеанса (или использует произвольный идентификатор) с сервера и с помощью некоторых средств (XSS атаки, MITM атаки и т.д.) заставляет другого пользователя использовать этот идентификатор сеанса для аутентификации на вашем сервере. В случае если ключ сессии не был изменен сервером, злоумышленник может завладеть сессией пользователя и выдать себя за него
Следовательно, отключение этой функции - это большой риск, а отдача от ее отключения также довольно мала. Я бы посоветовал вам (и всем, кто читает это) не отключать эту встроенную функцию, на самом деле, не отключайте ни одну из функций безопасности Django, не подумав хорошенько об этом.
Что касается связывания неаутентифицированного поведения с аутентифицированным поведением, то это лучше делать путем хранения данных путем их сериализации в самой сессии пользователя, как описано во втором методе этого ответа от Gonzalo.