Создание сайта. Часть 9: cookie и сессии

Почти последняя статья серии "Создание сайта". Полное содержание серии - в конце статьи.

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

Почему так сложно? Протокол HTTP не поддерживает постоянное подключение. Браузер отправил запрос на сервер и отключился. Сервак собирал ответ, отправил на адрес и тоже отключился. Браузер получил ответ, но ему все равно, почему это пришло, он "не помнит", что сам его запрашивал. Он просто строит пользователю страницу и опять отключается. При таких отключениях освобождаются все переменные, закрываются рабочие потоки, чистится память и т.д. Но иногда в этом обмене информацией нужен некий буфер, где будут храниться промежуточные результаты обмена данными, пока сервер/браузер в отключке. Эти данные возможно понадобятся в очередном запросе/ответе. И тогда буфером могут служить файлы cookie и сессий.

Пример #1. Браузер запросил капчу. Веб-сервер ее сгенерировал и отдал. Браузер нарисовал картинку. Все, отработали. Догадки юзера о содержимом капчи уже не волнуют ни сервер, ни браузер. Когда юзер введет код, браузер просто отправит данные формы на сервер, не зная, что именно отправляет. Там их должен получить назначенный для формы скрипт, который знает, что пришло. Он проверит правильность введенной капчи. Но при этом сервер не помнит, какую именно капчу он отдал и сообщить ее скрипту не может! Вот поэтому правильный код капчи пишется в сессионный файл. Скрипт прочитает в нем значение, сравнит и полученным и даст ответ.

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

Внимание, вопрос: почему в примере выше нужно хранить правильную капчу именно на сервере, а не в cookie клиента? Из соображений безопасности и здравого смысла :) Куки доступны клиенту для редактирования и при желании он может их исправить, как ему удобно. Применительно к капче, он может вписать в печеньку код, который при проверке заведомо окажется правильным. К сессионным файлам юзер доступа не имеет.

Пример #2. Использование сессий для обмена данными между скриптами на сервере. Так у меня в одном проекте обновлялить учетные данные посетителя и смена пароля. На html-странице две формы, методы POST. Каждую форму обслуживают отдельные php-скрипты. О результате своей работы скрипты сообщают тестовыми сообщениями типа "данные изменены" или "ошибка ...", которые они пишут в файл сессии. После отработки - редирект на эту же страницу с формами. При сборке страницы генератор данных читает сообщения из файла сессии и выдает их в шаблон для информации пользователю. При этом из сессии записи удаляются. Можно сделать все иначе, но надо было именно так.

Что почитать по теме печенек и сессий кроме инета: достаточно справки PHP, раздел "Расширения для работы с сессиями" и по функции setcookie().

Безопасность

У файлов сессий и cookie есть параметр – время жизни. Это один из аспектов безопасности. По умолчанию в PHP время жизни сессии 24 минуты, но в конечном счете его определяет кодер. Если учесть, что обычно область применения сессий – обмен данными между серверными скриптами, этого времени достаточно. Если нужно хранить данные долго, то лучше использовать для этого БД.

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

Сессии, в свою очередь, действительно должны быть короткими. Если хакер найдет к ним подход (взломает сервер, сможет угадывать SID, придумает очень шустрый brute-force), тогда под угрозой окажутся все посетители сайта.

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

Еще один параметр безопасности сессии – имя файла. Пример: юзер зашел в защищенную паролем зону сайта. Сервер создал для этого юзера файл сессии и записал в него флаг, означающий, что пользователю разрешено находиться в защищенной зоне. Имя файла сессии сервер отправил браузеру. Когда юзер будет перемещаться по закрытой части сайта, браузер с запросом страницы сообщит серверу это имя файла. Сервер проверит наличие флага в файле и вернет ответом защищаемую страницу. Если флага или файла не будет, тогда браузер получит страницу предупреждения или авторизации или Error 403 или что угодно, но не защищаемую страницу.

В итоге целью хакера становится имя файла сессии. Зная только его, он может со своего компа прикинуться тем самым пользователем. Более того, если он сможет воссоздать алгоритм задания имени сессионного файла, тогда у него появится возможность представиться любым посетителем сайта, которому сейчас создана сессия.

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

Есть несколько способов усложнить жизнь хакеру в поиске сессий, читайте об этом в статье "Безопасность сайта. Защита сессии". Как осложнить воровство печенек c компа конечного пользователя, рассказывать бесполезно =)

Пример #3, типа "найди ошибку" (из личного опыта). Как сказано выше, сессии живут мало, но их можно использовать для хранения капчи. А что, если юзер надолго зависнет на странице? Скажем, где-нить за пару часов осилит статью и захочет прокомментировать. И получит "неверная капча" только потому, что сессия уже закрылась. Некрасиво.. Я задумался на эту тему и сделал на сайте следующее "удобство" юзеру: если созданный для юзера файл сессии не найден на сервере, значит принимаем коммент без проверки капчи. По моим расчетам, спамер, даже зная о такой послабухе, смог бы нафлудить максимум 24 поста в сутки (время сессии было 1 час). Вряд ли бы он на это пошел.

Найдите в этих рассуждениях ошибку :) А она была, т.к. некий гад повадился постить мне по 5 комментов за несколько секунд. Это был спам-бот, который как-то проходил мимо капчи.

Ответ: "если созданный для юзера файл сессии не найден на сервере".. На деле сервер не проверяет, кому принадлежит сессия, поэтому если в сессионную печеньку вписать что-то левое, скрипт не найдет файл и, считая, что просто время сессии истекло, примет комментарий! Т.о. можно было вообще сайт положить в два счета. Но я во-время понял, где дыра, и пофиксил ее :)