PHP Cookie – практические примеры использования

Как понять, что ваши данные в опасности

Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?

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

Что хранят cookie

Допустим, мы зашли на сайт интернет-магазина ошейников для собак и выбрали французский язык (почему бы и нет). Добавили в корзину пару шлеек и поводок. Что будет, если мы закроем вкладку и зайдём на сайт снова? Всё останется прежним: интерфейс на французском и три товара в корзине. Магия? Нет, cookie.

Cookie — один из инструментов, который формирует так называемый фингерпринт каждого пользователя в сети. Его можно сравнить с «отпечатком пальца», по которому можно узнать, что за человек покупает ошейник для собаки.

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

Открываем панель разработчика в Chrome и переходим на рандомную статью на «Хабре». Во вкладке Network находим первый запрос, и в хедерах видим как проставляются cookie:

И в респонсе (ответе) видим cookie:

Set-Cookie: fl=ru; expires=Fri, 25-Feb-2022 08:33:31 GMT; Max-Age=31536000; path=/

Тут уже работает логика и Google (если очень нужно): cookie типа fl=ru(параметр, вероятно, отвечающий за язык) или те, которые хранят товары в корзине — постоянные cookie. Они не меняются, если пользователь их не трогает.

Например, при авторизации на сайте, в файл cookie проставляется условный session_id — уникальный идентификатор сессии на данный момент времени, к которому привязаны текущий браузер и пользователь.

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

Sql-инъекции кода

Давайте немного углубимся через ещё одну аналогию. Допустим, мы работаем официантом в элитном ресторане. Гости периодически просят изменить состав блюд. Официант отмечает, какие изменения внести в меню.

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

«ДОБАВИТЬ перец И УБРАТЬ сахар».

Вот и всё. Пранк удался. Но мы на стороне добра, так что вместо того, чтобы заменять заказ, мы проверим, как на кухне умеют фильтровать изменения. Как этим пользуются хакеры? SQL injection — это намеренное внесение в базу данных извне. В нашем примере, кухня — это база данных. SQL-запросы — заказы от официантов.

Авторизация и аутентификация

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

Давайте представим, что мы приглашены на конференцию по автоматическому тестированию. Мы приходим, а на входе нас встречают добродушные помощники организаторов, которые спрашивают наше имя. «Лаврентий Куашников», — отвечаем мы и показываем паспорт. Организаторы ищут нас в списке и видят, что мы спикер. Нам выдают бейдж и проводят в отдельное помещение, где мы можем расположиться и подготовиться к выступлению.

Аутентификация — это проверка на соответствие заявленного имени пользователя (паспорта) с идентификатором в системе (Лаврентий Куашников). Авторизация — это предоставление нам прав в соответствии с нашей ролью в системе (отдельная комната для спикера).

Авторизация с использованием php cookie

Для примера я создам 2 формы. Первая с одним единственным полем, в которое будем писать свое имя. Пока не будет введено и отправлено имя, пользователю будут недоступны некоторые элементы страницы. То есть, если он не авторизован, то какие-то функции сайта от него будут скрыты, а так же показано приветствие.

Код PHP

Теперь осталось в HTML вставить нужные переменные.

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation).

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Время жизни cookie в php

Если не указан третий параметр (Expires), то куки будут храниться до окончания сессии, то есть пока вы не закроете браузер. Но можно выставить и другие временные рамки, к примеру на 1 час или на 1 день и т. д. Вот некоторые примеры:

Этого вполне достаточно, но многие интересуются, как сделать так, чтобы куки жили вечно или сделать время жизни бесконечным. Не очень понимаю в каких случаях это может понадобиться, однако ответ на этот вопрос будет — НЕТ, нельзя. Но можно поставить максимальное время. Пишется так: 0x7FFFFFFF — дата 19.01.2038 года.

Двухфакторная аутентификация

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

Как аутентифицировать пользователей с помощью промежуточного программного обеспечения passport.js

До сих пор мы видели, как аутентифицировать пользователей с помощью файлов cookie и сеансов. Теперь мы увидим третий метод аутентификации.

Passport.js – это промежуточное ПО для аутентификации в Node, которое позволяет аутентифицировать пользователей с помощью сеансов и OAuth. Он также позволяет создавать собственные стратегии и многое другое.

Этот код устанавливает все необходимые модули для определения подходящей локальной стратегии. Стратегия passport-local позволяет аутентификацию с помощью имени пользователя и пароля.

Как аутентифицировать пользователя с помощью сеансов

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

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

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

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

Предположим, вы делаете карточки для каждого друга и храните их при себе. Когда вы их видите, вы назначаете способ сопоставления карты с человеком для облегчения идентификации. Таким образом, информация не хранится у клиента и, следовательно, более безопасна.

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

express-session создает промежуточное ПО для сеансов, которое позволяет легко настраивать сеансы и управлять ими.

Серверное хранилище по умолчанию – это MemoryStore. Чтобы хранить информацию о сеансе в виде файлов JSON, вам потребуется хранилище файлов сеанса. Приведенный ниже код делает следующее:

1. Устанавливает приложение Express
2. Он сообщает промежуточному программному обеспечению запрашивать аутентификацию, если ничего не указано, и в противном случае проверяет, совпадают ли имя пользователя и пароль.
3. Если нет, ему снова нужно сделать тот же запрос на аутентификацию, иначе сеанс будет установлен.
4. Затем он добавляет имя пользователя в качестве атрибута пользователя и впоследствии проверяет его.

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

let app=express()
app.use(session({
  store: new File_Store,
  secret: 'hello world',
  resave: true,
  saveUninitialized: true
}))
app.use('/', (req,res,next)=>{
  if(!req.session.user)
  {
    console.log("Session not set-up yet")
    if(!req.headers.authorization)
    {
      console.log("No auth headers")
      res.setHeader("WWW-Authenticate", "Basic")
      res.sendStatus(401)
    }
    else
    {
      auth_stuff=new Buffer.from(req.headers.authorization.split(" ")[1], 'base64')
      step1=auth_stuff.toString().split(":")
      console.log("Step1: ", step1)
      if(step1[0]=='admin' && step1[1]=='admin')
      {
        console.log('GENUINE USER')
        req.session.user='admin'
        res.send("GENUINE USER")
      }
      else
      {
        res.setHeader("WWW-Authenticate", "Basic")
        res.sendStatus(401)
      }
    }
  }

Как аутентифицировать пользователя с помощью файлов cookie

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

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

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

Но как сервер будет отслеживать, какие пользователи уже аутентифицированы, а какие нет? Вот тут и пригодятся куки.

Согласно w3.org, файлы cookie определяются как:

Как получить, прочитать, проверить cookie в php

В этом нам поможет глобальный массив COOKIE. Чтобы получить значение куки нам нужно вызвать ее по имени.

Как вы уже догадались, на экран выведется пятерка. Теперь сделаем проверку. Если данная кука была установлена, то выедем одно сообщение, если не была, то другое.

Есть один маленький нюанс. При первом заходе на страницу будет выведено сообщение, что куки не установлены, однако, если заглянуть в консоль браузера, то увидим, что она там есть. В чем же дело? Элементарно. Дело в том, что запрос на проверку и сама установка куки идут ОДНОВРЕМЕННО. Поэтому сообщение об успешной установке мы увидим только после следующей перезагрузке страницы.

Теперь у нас есть условие и его можно использовать в некоторых случаях.

Как удалить или очистить (unset) куки в php

Удаление куки в PHP можно сделать двумя способами. Оставить значение пустым или установить прошедшую дату, со знаком минус:

Как установить куки в php

Все не так сложно, как может показаться. Установка cookie происходит следующим образом:

Это базовые значения, которые обязательны для заполнения. Но параметров гораздо больше, а именно 7! Семь, Карл! И вот для чего каждый из них нужен.

В подавляющем большинстве случаев используются первые 3 параметра чтобы записать cookie в PHP. То есть имя, значение и время жизни. Этого вполне достаточно для полноценной работы. Давайте к практике.

Здесь я установил cookie name со значением — 5, которая удалится через 1 минуту.

Напутствие

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

Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра!

Стандарт saml

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Стандарты oauth и openid connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2022 гг., а текущая версия 2.0 опубликована в 2022 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Счетчик просмотров страницы на php cookie

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

Потом просто выводим на странице переменную count. Протестировать и посмотреть пример работы PHP cookie можно на этой странице:

Демо

Токены и сессии

Давайте представим, что мы захотели вступить в тайный клуб любителей настольных игр. Туда просто так не попасть. Сначала нужно доказать, что мы подходим на роль члена клуба — любим настолки.

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Заключение

На этом я завершаю обзор различных методов аутентификации в Node.

Используемый здесь код далек от идеала, но я надеюсь, что он поможет кому-то, кто только начал изучать аутентификацию и чувствовал себя подавленным.