Разница между cookie и сессиями
Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте. И там я написал, что при авторизации надо записать информацию об этом (логин и шифрованный пароль) в cookie, либо в сессию. Однако, возникает вопрос: «Что же выбрать: cookie или сессии?«. В этой статье я собираюсь разобрать разницу между сессиями и cookie, чтобы Вы окончательно определились с выбором.
Принципиальная разница между cookie и сессиями состоит в том, что cookie полностью хранятся в браузере пользователя (то есть на компьютере клиента), а при сессиях в cookie хранится только идентификатор сессии, а вся информация лежит на сервере в специальном уникальном файле. Именно из этого базового различия вытекают все остальные.
У Вас серьёзный сайт, на котором у людей лежат крупные суммы денег (например, как WebMoney). Ваш посетитель пришёл в какое-нибудь Интернет-кафе, авторизовался, но выйти забыл (уверен, что с каждым из Вас это происходит регулярно). Дальше приходит злоумышленник заходит на его аккаунт и забирает cookie. Дальше процесс очевиден. А если бы использовались сессии, то по умолчанию через 15 минут бездействия пользователя происходил бы автоматический выход (файл с данными сессиями бы стирался). И ничего такого бы не произошло. Более того, ввиду того, что каждая сессия имеет уникальный идентификатор, то смысл воровства идентификатора сессии (а больше ничего взять не получится) уже отсутствует. Когда злоумшыленник придёт домой, этот идентификатор ему уже не поможет.
Именно по этой причине cookie так популярны при работе с механизмом авторизации.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 3 ):
А можно ли как-нибудь сохранить в куки объект созданного мною класса?
Можно преобразовать его в строку и сохранить.
Но когда пользователь нажимает сохранить пароль в браузере а так делают многие то данные по любому в cooci браузера сохраняются.
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Что такое куки (cookies): определение и типы
Читайте больше о типах куки и узнайте, зачем их используют в маркетинге
Куки — это текстовый файл, который передает сервер браузеру пользователя.
Содержание
Он создается на основе заполнения форм на сайтах, которые включают имя, логин, пароль и другие данные. Каждый раз, когда пользователь открывает уже посещаемую ранее страницу, его браузер отправляет этот файл серверу в виде HTTP запроса.
Для чего нужны куки?
Именно куки позволяют не вводить логин и пароль каждый раз при посещении сайта.
Зачем используют куки в маркетинге?
Для трекинга. Программисты и маркетологи используют куки, чтобы собрать информацию о пользователях для дальнейшего её анализа. Отслеживают посещаемые сайты, просматриваемые страницы, по каким ссылкам переходят, чем интересуются. В результате создают релевантную и сегментированную рекламу для каждого клиента. Таким образом, чем больше сайт размещает объявлений на разных площадких, тем больше информации о пользователях будет передано на сервер.
Недостатки куки
Мифы о куки
Многие пользователи уверены, что куки — это не просто файл, а целый код, который угрожает их компьютеру. Отслеживание информации возможно только если человек сам разрешил это или просто ходит по сайту. Вот несколько популярных заблуждений насчет кукиз.
Типы куки
Сессионные куки
Сессионные или временные куки могут существовать только в тот промежуток времени, когда пользователь находится на сайте. После того, как он закрыл окно браузера, куки удаляются.
Постоянные куки
Они удаляются либо через определенный промежуток времени, либо когда пользователь сам очистит куки. Таким образом, браузер передает их на сервер при каждом посещении сайта.
Защищенные куки
Этот тип куки передают только через шифрованное соединение HTTPS.
HTTPOnly куки
К этому типу куки нельзя обратиться через API. Это предотвращает кражу куки.
Время от времени нужно удалять куки, так как они занимают место на жестком диске и влияют на скорость работы компьютера, а также позволяют другим пользователям заходить на сайты через ваши сохраненные пароли.
Во многих браузерах вы можете отключить сбор куки, но иногда это не позволяет полноценно пользоваться сайтами.
Как почистить куки в Google Chrome?
Для удаление куки можно использовать специальные программы, например, CCleaner.
Также искали с «Куки (cookies)»
Оценка: 4 / 5 (9)
Что такое cookie в браузере и почему на многих сайтах предупреждают об их использовании?
Содержание
Содержание
Многие сайты выдают предупреждение об использовании cookie-файлов и запрашивают согласие пользователя. Что это такое, какую информацию несут такие файлы и безопасно ли передавать куки — расскажем подробнее.
Что такое cookie и как это работает
Происхождение термина связывают с другим понятием — magic cookie. Так называли небольшой объем данных, передаваемых между программой и получателем. Как правило, эти данные не имели ценности для получателя до тех пор, пока он не отправит их обратно той же программе.
Самое простое сравнение — номерок в гардеробе. Сам по себе он не имеет практически никакой ценности, но, предъявив номерок в гардеробе, вы можете получить свое пальто обратно. Таким образом, его ценность проявляется только в момент, когда вы обращаетесь в гардероб: именно номерок помогает гардеробщице «распознать» вас в качестве владельца конкретной вещи. Файлы cookie — это своеобразный номерок, который позволяет идентифицировать каждого отдельного пользователя на сайте.
Принцип работы достаточно простой. Когда вы заходите на сайт, сервер отправляет не только данные о странице, но и файл куки. Он записывается непосредственно на ваш компьютер, как правило, в рабочих файлах самого браузера. По мере того, как вы ходите по сайту, файл дополняется различной информацией. Если вы повторно зайдете на этот сайт, браузер отправит серверу cookie, благодаря чему сайт «узнает» вас.
Обычно файл хранится в пользовательских данных (User Data) в папке браузера. Документ не имеет разрешения.
Если говорить о Firefox, то куки представлены набором файлов. Просмотреть содержимое можно через текстовый редактор, однако информация из-за своего формата будет нечитабельной.
Все cookie можно разделить на несколько основных групп:
Последние файлы считаются запрещенными, многие поисковые системы блокируют сайты, которые пытаются подгрузить зомби-cookie к вам на компьютер.
Какая информация хранится в cookie
Насколько хорошо сайты знают вас по информации из куки? Это зависит от конкретного интернет-ресурса.
Данные сессии. В первую очередь, в файле сохраняются логин и пароль, чтобы после каждого обновления страницы пользователям не приходилось вбивать их повторно. Cookie способны собирать информацию о посещенных страницах и времени, проведенном на сайте, а также фиксировать отдельные действия, например, заполнение различных форм.
Настройки профиля. Cookie сохраняют языковые настройки, вашу корзину (даже если вы еще не зарегистрировались на сайте), валюту покупки, геолокацию и так далее. Самый яркий пример — интернет-магазины, которые автоматически подставляют нужную валюту и город доставки, а также сохраняют товары в корзине.
Идентификационные данные. Под этим подразумевают версию браузера или операционной системы, тип устройства, время посещения и не только. Файл куки создается для каждого конкретного браузера, поэтому сайт посчитает одного и того же человека как разных пользователей, если он зайдет на ресурс через разные браузеры.
В большинстве случаев cookie позволяют получить практически полную карту «путешествий» пользователя по сайту. Если же говорить о куки-файлах для отдельных рекламных баннеров, то они могут собрать информацию о вас, даже если вы посещали разные домены, на которых имелись баннеры от одного разработчика.
Безопасность cookie и правовое регулирование
Некоторые пользователи опасаются файлов cookie, поскольку считают их полноценным софтом, способным украсть личную информацию с компьютера. Это заблуждение, поскольку куки не относятся к исполняемым файлам и не производят никаких действий самостоятельно.
Тем не менее, злоумышленники могут использовать cookie, чтобы зайти в ваш личный аккаунт, поскольку в этих данных передается логин и пароль для авторизации. Применяются несколько методов кражи:
Взлом сессии. Хакеры могут перехватить незашифрованный интернет-трафик и извлечь конфиденциальную информацию. Чтобы это предотвратить, необходимо использовать только зашифрованное соединение HTTPS. Однако и это не гарантирует полной безопасности, поскольку отправка самих куки может идти по HTTP. Файлы cookie защищены только в том случае, если атрибут secure находится в значении true.
Например, для Google Chrome есть расширение CookieEditor, которое позволяет посмотреть и редактировать сохраненные куки, в том числе изучить конкретные атрибуты.
Подмена cookie. Возможны атаки на сервер, когда злоумышленник модифицирует куки-файл и получает с этого какую-либо выгоду, например, меньшую сумму заказа. Для предотвращения таких ситуаций сайты передают в куки только уникальный идентификатор сессии, а другая информация хранится на самом сервере, что делает подобную атаку затруднительной.
Межсайтовые cookie. Эти атаки используют уязвимости браузеров и направлены на захват идентификатора вашей сессии. Именно поэтому рекомендуется регулярно обновлять свой браузер.
Кража cookie. Специализированное вредоносное ПО может украсть ваши куки, после чего злоумышленник сможет через них авторизоваться на сайте даже с протоколом HTTPS.
Проблема избыточного сбора информации об интернет-пользователях начала подниматься еще в начале 2000-х. В мае 2018 года Европейский Союз выпустил Общий регламент защиты персональных данных (GDPR). В документе были определены основы работы с cookie:
GDPR предусматривает штрафы до 20 миллионов евро. Самое громкое дело произошло в 2019 году, когда авиакомпанию Vueling оштрафовали на 30 тысяч евро. На сайте компании пользователь не мог отказаться от использования куки. В России действует закон 152-ФЗ «О персональных данных», который контролирует сбор личной информации.
Чтобы избежать штрафов, каждый сайт при использовании cookie должен выдавать пользователям соответствующее уведомление, которое предполагает ответное действие.
Однако здесь может быть несколько подводных камней, которые намеренно или случайно оставляют разработчики сайтов, например:
Как очистить и отключить cookie
Пользователи могут очистить хранящиеся на компьютере куки или полностью запретить их работу. Сделать это можно с помощью стандартных настроек браузера.
Google Chrome
Чтобы стереть cookie, перейдите через главное меню в раздел «История» (Ctrl+H) и в левой части нажмите «Очистить историю». Далее выставьте галочку только для cookie и сверху выберите «За все время». Остается только подтвердить удаление.
Чтобы настроить удаление куки, необходимо в настройках браузера зайти в раздел «Конфиденциальность и безопасность». Выберите пункт «Файлы cookie».
В новом окне вы сможете выбрать, в каких случаях блокировать куки (только для сторонних сайтов или всегда).
Mozilla Firefox
В меню «Журнал» выберите подпункт «Удаление истории». Укажите, за какое время удалить данные, и поставьте галочку напротив «куки».
В разделе «Приватность и защита» вы также можете удалить куки для каждого отдельного сайта. Чтобы полностью отключить куки, в этом же разделе выберите нужный уровень защиты и выставьте блокировку.
Opera
Через иконку в левой части зайдите в блок «История» и выберите «Очистить историю». По аналогии с Chrome укажите период очистки и оставьте галочку только напротив cookie.
Opera также позволяет отключить отправку куки полностью. В разделе «Дополнительно» войдите в «Файлы cookie и прочие данные». В открывшемся меню можно поставить полную блокировку.
Обратите внимание, что полная блокировка куки может привести к некорректной работе сайта, когда вам придется постоянно вводить данные авторизации вручную.
Как обезопасить себя от кражи cookie
Если вы не хотите полностью отключать куки, но при этом беспокоитесь о своей безопасности, то следуйте нескольким рекомендациям:
Когда сайт не предупреждает об использовании cookie, это не означает, что они отключены. Большинство мелких ресурсов просто не утруждаются оповещением посетителей, поэтому проверять этот факт придется вручную.
В домашних условиях куки на компьютере – вполне безопасное и обыденное дело. Они предлагают массу удобств: сохранение логина и пароля, корзины товаров, геолокации и так далее. Все это экономит время. Но при использовании общедоступных точек Wi-Fi от сохранения куки лучше воздержаться, поскольку общественные сети более уязвимы в плане атаки злоумышленников.
Разница между Cookies и сессиями
Пожалуйста, объяснить мне простыми словами, а не заученными терминами, как и с чем работать? Что и для чего надо? Можно с примерами в которых будет пояснение, спасибо.
3 ответа 3
Это разные явления.
Cookie — это просто пара имя-значение, которую (точнее, которые) сервер может оставить у клиента (браузера). Наглядно:
Упрощенно, не затрагивая тонкости — все, вот все, что представляют собой cookies.
Сессии — более эфемерное понятие, которое не привязано к какой-то конкретной реальной технологии. Это просто некая методика, которая позволяет отличить одного клиента от другого, и, как правило, где-то хранить связанные с каждым клиентом данные.
Еще можно хранить идентификаторы сессий в других местах. Например, Local Shared Objects («флэшевские cookie»), использовать возможности хранилищ HTML5, и еще ряде менее тривиальных мест, но PHP этого «из коробки» не умеет.
Соответственно, раз и cookies и поддержка use_trans_sid (перезаписи адресов) отключены, то PHP не может нигде оставить у клиента «метку». И сессии, по сути, не работают. Это, в общем-то, не должно быть проблемой — если клиенту надо — он включит cookies.
Еще момент. Сами по себе сессии не дают авторизации — это только хранилище. Авторизацию делаете Вы сами (или фреймворк, которым Вы воспользовались). Вы пользуетесь тем, что данные, связанные с сессией (в типичной PHP’шной реализации) хранятся на сервере, и клиент их там подменить не может.
Соответственно, когда клиент аутентифицируется — в сессии сохраняется кто он. Обратно — если у нас в сессии записано кто он — можно этому верить. Вся дальнейшая логика — пускать ли клиента, давать ли ему какие-то возможности и т.д. — на Вас.
Как работать с куки и сессиями? В каждом файле надо делать проверку на существование сессии, для того чтобы если их нет то человек не смог зайти на эту страницу?
Зависит от того, что Вы хотите, и от того, как Вы все строите. Если к этой странице должен быть доступ только у авторизованных пользователей — да, как вариант, так.
Иногда все запросы пропускают через один скрипт-«диспетчер». Иногда во все скрипты в начало вставляют include, которое инициализирует общую для всего сайта логику (сессии, авторизация).
PHP для начинающих. Сессия
Начну с сессий — это один из самых важных компонентов, с которыми вам придется работать. Не понимая принципов его работы — наворотите делов. Так что во избежание проблем я постараюсь рассказать о всех возможных нюансах.
Но для начала, чтобы понять зачем нам сессия, обратимся к истокам — к HTTP протоколу.
HTTP Protocol
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и（•_ㅅ_•）
Чтобы не ходить вокруг да около, давайте я вам приведу пример общения по HTTP протоколу.
Вот пример запроса, каким его отправляет ваш браузер, когда вы запрашиваете страницу http://example.com :
А вот пример ответа:
Это очень упрощенные примеры, но и тут можно увидеть из чего состоят HTTP запрос и ответ:
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.
Как можно заметить, заголовки отправляемые браузером (Request Headers) и сервером (Response Headers) отличаются, хотя есть и общие и для запросов и для ответов (General Headers)
Сервер узнал нашего пользователя по присланным cookie, и дальше предоставит ему доступ к личной информации. Так, ну вроде с сессиями и HTTP разобрались, теперь можно вернутся к PHP и его особенностям.
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».
Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Запустите браузер, и откройте в нём Developer Tools (или что там у вас), далее перейдите на страницу http://127.0.0.1:8080/session.start.php — вы должны увидеть лишь пустую страницу, но не спешите закрывать — посмотрите на заголовки которые нам прислал сервер:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем — теория совпала с практикой, и это просто отлично.
Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Всё тайное становится явным
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ — привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу — будем запоминать User-Agent и проверять его каждый раз:
Ключевое слово в предыдущем абзаце похоже, в реальных проектах cookies уже давно «бегают» по HTTPS протоколу, таким образом никто их не сможет украсть без физического доступа к вашему компьютеру или смартфону
Стоит упомянуть директиву session.cookie-httponly, благодаря ей сессионная кука будет недоступна из JavaScript’a. Кроме этого — если заглянуть в мануал функции setcookie(), то можно заметить, что последний параметр так же отвечает за HttpOnly. Помните об этом — эта настройка позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах.
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
А есть ли жизнь без «печенек»?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:
А если надо сессию в базе данных хранить?
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() 😉
Когда умирает сессия?
За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.
Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:
Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Блокировка
Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки 🙂
Но давайте ещё раз по шагам:
«Воткнутся» в данную ошибку очень легко, создайте два файла:
Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».
«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку 🙂
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…
«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:
— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:
Таким образом, блокировка будет снята сразу по прочтению данных сессии.
— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:
В заключение
В этой статье вам дано семь заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!