Является ли cookie распространенной и безопасной реализацией сессии?

Question

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

Итак, мой вопрос: какая наиболее распространенная реализация (наи клиент и сервер)?Может кто-нибудь привести пример (может быть, просто описание) кодов?( Я бы не хотел использовать предоставленную поддержку сеанса внутри пирамиды для изучения )

Answer 1

Самая распространенная реализация сессий - это использование куки.

Файл cookie предоставляет способ хранения произвольного фрагмента текста, который обычно используется в качестве идентификатора сеанса. Когда cookie отправляется вместе с HTTP-запросом, сервер (технически код, выполняющийся на нем) может использовать текст cookie (если он существует), чтобы распознать, что он видел клиента раньше. Текст в куки обычно предоставляет достаточно информации для извлечения дополнительной информации из базы данных об этом клиенте.

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

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

Альтернативный подход - сохранить идентификатор сеанса - использовать параметр GET в URL-адресе (например, в чем-то вроде http://example.com/some/page?sid=4s6da4sdasd48, тогда параметр sid GET выполняет ту же функцию, что и строка cookie). При таком подходе ко всем ссылкам на другие страницы сайта добавляется параметр GET.

Answer 2

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

Поэтому, когда вы получаете запрос, первое, что вы делаете, это ищите cookie. Если его нет, создайте запись сеанса (cookie + метка времени истечения) в таблице базы данных. Если он есть, посмотрите его и убедитесь, что он не истек; если есть, создайте новый. В любом случае, если вы создали новый файл cookie, вы можете передать этот факт в более поздний код, чтобы он знал, нужно ли ему запрашивать логин или что-то в этом роде. Если вам не нужно было создавать новый файл cookie, сбросьте метку времени истечения, чтобы не завершать сеанс слишком рано.

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

Если у кого-то cookie-файлы отключены, то их сеансовый cookie-файл всегда будет новым, и любые функции на основе сеанса не будут работать.

Answer 3

Сессия - это (обычно) файл cookie, имеющий уникальное значение. Это значение отображается на значение в базе данных или хранится в памяти, которое затем сообщает вам, какой сеанс загрузить. В PHP есть альтернативный метод, в котором он добавляет уникальное значение в конец каждого URL-адреса (если вы когда-либо видели PHPSESSID в URL-адресе, теперь вы знаете, почему), но это имеет последствия для безопасности (теоретически).

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

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