Использование файлов cookie для состояния веб-сеанса - какие подводные камни?

Question

Использование состояния внутрипроцессного сеанса является злым, когда дело доходит до масштабирования веб-приложений (плохо работает с кластерами, взрывается при перезапуске сервера).

Предполагая, что вам просто нужно хранить небольшое количество информации в состоянии сеанса, в чем недостаток использования зашифрованных файлов cookie для этой цели, а не конкретных серверов состояний / дБ?

Очевидно, что использование куки-файлов создаст небольшую нагрузку на сеть, и, очевидно, вы работаете в предположении, что куки-файлы включены на клиентском браузере / мобильном устройстве.

Какие еще подводные камни можно увидеть с подхода?

Это хороший вариант для простых, масштабируемых и надежных сеансов?

Answer 1

Это отличный подход для простых, масштабируемых и надежных сессий. Конечно, качество вашего криптозащиты очень важно, и это часто бывает сложно сделать правильно, но это возможно.

Я не согласен с некоторыми другими постерами:

Любая атака воспроизведения, которая может быть запущена против зашифрованного значения cookie, может быть запущена против ключа сеанса, хранящегося как cookie. Используйте https, если это имеет значение.

Данные сеанса, хранящиеся на сервере состояний или в базе данных, также теряются при удалении cookie; когда ключ сеанса утерян, сеанс больше не может быть получен.

Answer 2

Ну, обычно для идентификатора сеанса используется cookie, поэтому, если объем информации невелик, было бы неплохо сохранить информацию в cookie, хотя вы не должны хранить ничего ценного (например, CC номера, SSN и т. д.) действительно должны храниться в cookie, даже если они зашифрованы.

Я не эксперт, но по своему опыту я нашел следующее (по крайней мере, с использованием PHP и ASP.Net).

Cookie

• [pro] Хорошо масштабируется, поскольку передается при каждом запросе
• [pro] Cookie может потребоваться для отправки только через соединение SSL
• [pro] Могут использоваться кросс-серверные технологии и кросс-серверные машины
• [con] Данные передаются по каждому запросу и ответу
• [con] Необходимо включить в браузере

State Server / DB

• [pro] Данные хранятся только на сервере
• [pro] Данные сохраняются даже после удаления пользователем файлов cookie
• [pro] Могут использоваться межсерверные технологии
• [con] требует, чтобы идентификатор передавался по запросу / ответу (таким образом, требуется куки или добавление к каждому URL)
• [con] плохо масштабируется в режимах по умолчанию, но если целые машины могут быть выделены специально и исключительно для состояния, то это не большая проблема. Существует множество других методов масштабирования, которые можно использовать для обеспечения масштабируемости.
• [con] Требуется переменная идентификатора сеанса, передаваемая через URL, cookie или другими способами, чтобы пользователь оставался связанным с данными.

Answer 3

Еще одна ловушка заключается в том, что они могут быть украдены и воспроизведены на вашем сайте.

Кстати: вместо того, чтобы хранить некоторые вещи в куки, вы также должны посмотреть, как хранить ключ в куки и использовать что-то вроде memcached (memcached работает на всех фермах серверов).