сессия — Безопасность в SESSION PHP и идентификация пользователя
Дайте совет. У меня форма регистрации валидируется JS, после успешной валидации аякс запросом пользователь добавляется в БД и должна открыться страница на которую имеет доступ только этот пользователь. Я в файле обработчике добавляю в сессию маил пользователя и проверку если существует такая сессия то происходит переадресация.
Мне правда кажется это какой то колхоз и пострадает безопасность, подскажите какие действия необходимо проделать сразу после регистрации чтобы идентифицировать пользователя.
PS при авторизации я в сессию добавляю ID юзера из БД а при регистрации не получается.
- php
- сессия
- регистрация
1
Почти все среднестатические веб-приложение в наше время, имеют авторизацию и регистрацию такого типа. Что именно вы думаете будет небезопасно? Сессия создаётся на сервере, взаимодетвие между клиентом и сервером у вас идёт по Ajax
Сервер воспринимает ваш Ajax
Клиент как обычный браузер клиент. То есть, безопасность вашего приложения, полностью зависит от вас, и именно в той схеме о которой вы рассказали, дыр по идее быть не должно. Советую вам больше сконцентрироваться на готовности к DDoS
, CSRF
, XSS
. И купите TSL
Сертификат. И да, скорее всего добавить ID
Пользовался при регистрации у вас не получаеться потому что на момент когда вы заносите ID
В сессию, он ещё не создана в базе данных, ну это конечно требует уточнений.
17
Возможно на похожий вопрос я когда-то давал ответ, загляните сюда. Если это не то, то дайте знать подробнее в чем суть вопроса.
Зарегистрируйтесь или войдите
Регистрация через Google
Регистрация через Facebook
Регистрация через почту
Отправить без регистрации
Почта
Необходима, но никому не показывается
Отправить без регистрации
Почта
Необходима, но никому не показывается
Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки
Авторизация и сессия | PHPClub
vlav
Новичок
- #1
Здравствуйте
Юзер проходит авторизацию, введенное им в форму имя и пароль ищется в базе и, в случае успеха, присваивается переменным сессии.
Далее при загрузке страницы делается запрос к базе с именем и паролем из сессии и, если найдено, авторизация подтверждается.
AnrDaemon
Продвинутый новичок
- #2
1. С какого перепугу у тебя пароль хранится в сессии?
2.
vlav
Новичок
- #3
AnrDaemon написал(а):
1. С какого перепугу у тебя пароль хранится в сессии?
2. Это может быть от кардинального непонимания механизма сессий.Нажмите для раскрытия…
Если быть точным, то хранится не пароль, а мд5 пароля. И в базе и в сессии. Вы бы что то подсказали или дали наводку где почитать…
Фанат
oncle terrible
- #4
Сессия на двух компьютерах существовать не может.
сессия и авторизация — это разные вещи.
судя по кривой реализации (парль в сессии, хотя нфига он там нужен?), причина проблемы в твоем коде
в чем конкретно заключается кривизна твоего кода, мы не знаем.
vlav
Новичок
- #5
Фанат написал(а):
Сессия на двух компьютерах существовать не может.
сессия и авторизация — это разные вещи.
судя по кривой реализации (парль в сессии, хотя нфига он там нужен?), причина проблемы в твоем коде
в чем конкретно заключается кривизна твоего кода, мы не знаем.Нажмите для раскрытия…
Спасибо, именно это я и хотел услышать
А как правильно делается авторизация?
Я думаю — надо после проверки пароля сгенерировать какой то токен и сохранить его в базе и в сессии, также сохранить в базе время создания токена.
Фанат
oncle terrible
- #6
Я бы просто писал в сессию ид пользователя.
Если надо проверять, забанен ли пользователь, то запрашивать из БД каждый раз по ид.
А если не надо, то зачем вообще базу дергать?
Вообще вариантов масса, но этот самый простой
vlav
Новичок
- #7
Спасибо.
У меня тут просто есть некоторые планы, и я понимаю, что отстал во многих вопросах. Хочу убедиться, что в ключевых точках не делаю ошибок.
vlav
Новичок
- #8
Фанат написал(а):
Я бы просто писал в сессию ид пользователя.
Если надо проверять, забанен ли пользователь, то запрашивать из БД каждый раз по ид.
А если не надо, то зачем вообще базу дергать?Вообще вариантов масса, но этот самый простой
Нажмите для раскрытия…
Извините, хочу еще раз уточнить — вы считаете, что достаточно при первом заходе, если имя пароль корректны, создать _SESSION[‘uid’] а затем просто проверять — если isset($_SESSION[‘uid’]) — то авторизация подтверждена? И этого достаточно ?
AnrDaemon
Продвинутый новичок
- #9
Ну, да, а что вас смущает?
vlav
Новичок
- #10
Спасибо, ничего не смущает, с наступившим!
vlav
Новичок
- #11
Здравствуйте, извините, что задаю эти вопросы, кому то они могут показаться глупыми, но для меня важно.
Можно ли в принципе на клиентской стороне зайти на какой то сайт, авторизоваться, и с помощью сторонних средств (инструментов разработчика, программы, каких то хакерских штучек) — посмотреть содержимое _SESSION ? Изменить его?
AnrDaemon
Продвинутый новичок
- #12
Переменные можно посмотреть только на сервере, ведь они существуют только во время выполнения скрипта.
Когда результат отослан клиенту, скрипт уже завершил работу.
Есть программы-отладчики, позволяющие контролировать выполнение скрипта.
Например, XDebug.
vlav
Новичок
- #13
Здесь
http://phpfaq.ru/sessions
написано про безопасность сессий:
Самый хрестоматийный — не передавать идентификатор через адресную строку. Об этом написано даже в php.ini, но это ограничивает функциональность сессий. Если вы решите последовать этому совету, то кроме session.use_trans_sid = 0 не забудьте session.use_only_cookies = 1
Желательно привязывать сессию к IP адресу: таким образом, если идентификатор будет украден, то злодей все равно не сможет им воспользоваться в большинстве случаев.Нажмите для раскрытия…
а как в принципе можно воспользоваться идентификатором сессии, украв его? Если он выдается один раз при старте у клиента и уникален каждый раз? Его в общем то несложно посмотреть в куках…
c0dex
web.dev 2002-…
- #14
@vlav, украв идентификатор можно стать тем, у кого был этот id, то есть получить его права
vlav
Новичок
- #15
c0dex написал(а):
@vlav, украв идентификатор можно стать тем, у кого был этот id, то есть получить его права
Нажмите для раскрытия. ..
Как? Записав у себя вручную куку с таким же именем? Идентификатор же меняется, когда у нее время жизни истекает?
c0dex
web.dev 2002-…
- #16
@vlav, как — вот так, по содержимому этой куки, а не по ее идентификатору онли.
Надо понимать и ограничения, связанные с временем жизни куки.
Но многие делают еще и привязку к браузеру, ip адресу клиента и прочее, просто так упереть куку на нормальном сайте — даст мало чего.
vlav
Новичок
- #17
в общем понятно, спасибо
AnrDaemon
Продвинутый новичок
- #18
vlav написал(а):
когда у нее время жизни истекает?
Нажмите для раскрытия. ..
Ключевое слово.
vlav
Новичок
- #19
Можно еще один глупый вопрос? С сессиями более менее разобрался. Где хранятся глобальные переменные PHP, которые присутствуют в GLOBALS (например были созданы как var XXXX в классе)? Собственно волнует вопрос безопасности. Может ли хакер на клиентском компьютере как то их считать?
WMix
герр M:)ller
- #20
vlav написал(а):
. Где хранятся глобальные переменные
Нажмите для раскрытия…
в памяти
vlav написал(а):
Может ли хакер на клиентском компьютере как то их считать?
Нажмите для раскрытия…
вспомним https://ru.wikipedia.org/wiki/Heartbleed
Файлы cookie WordPress и сеансы PHP
Файлы cookie были впервые изобретены в 1994 году программистом по имени Лу Монтулли. Без них Интернет был бы совсем другим местом. Независимо от того, входите ли вы в серверную часть своего сайта WordPress или закрываете раздражающее всплывающее окно, вы используете файлы cookie и взаимодействуете с ними каждый день (даже если вы этого не осознаете).
Вы, наверное, уже догадались, что когда мы говорим о файлах cookie, мы имеем в виду файлы cookie, используемые для хранения важной информации о посетителях на веб-сайте, а не вкусная шоколадная стружка. 🍪
Сегодня мы собираемся погрузиться в иногда запутанную тему файлов cookie и PHP-сессий. В частности, все, что вам нужно знать о том, как их использует WordPress, а также некоторые распространенные проблемы, о которых вы должны знать (особенно как разработчик), когда речь идет о размещении вашего веб-сайта, пользовательском коде или использовании стороннего плагина. На наш взгляд, эта тема недостаточно раскрыта.
Что такое файлы cookie?
Файл cookie (также называемый веб-файлом cookie, файлом cookie отслеживания, файлом cookie HTTP, файлом cookie браузера) — это небольшой фрагмент данных, сохраняемый браузером пользователя (Chrome, Firefox и т. д.) при посещении веб-сайта. Он содержит информацию о действиях в Интернете и обычно используется для персонализации взаимодействия с пользователем или для целей аутентификации и проверки. Сессионные и постоянные файлы cookie являются распространенными типами файлов cookie.
- Типы файлов cookie
- Как ядро WordPress использует файлы cookie
- Как сторонние плагины и темы WordPress используют файлы cookie
- Файлы cookie и кэширование WordPress
- Как просмотреть и очистить файлы cookie
- GDPR и файлы cookie
- сеансов PHP
Типы файлов cookie
Обычно используются два типа файлов cookie: сеансовые файлы cookie и постоянные файлы cookie .
Сеансовые файлы cookie
Сеансовые файлы cookie, также известные как временные файлы cookie, являются временными. К ним не привязана дата истечения срока действия, и они хранят только информацию о том, что пользователь делает в течение одного сеанса . Сеанс — это просто случайно сгенерированное/уникальное значение, которое присваивается, когда кто-то посещает веб-сайт. Сеансовые файлы cookie временно хранятся в памяти и автоматически удаляются при закрытии браузера или завершении сеанса.
Рекомендуемая литература: Как улучшить лимит памяти PHP в WordPress.
Постоянные файлы cookie
Постоянные файлы cookie, как вы могли догадаться, содержат дату истечения срока действия. Они сохраняются намного дольше и хранятся на диске до истечения срока их действия или до тех пор, пока пользователь не очистит их вручную . Их также иногда называют «отслеживающими файлами cookie», поскольку это типы файлов cookie, которые используют Google Analytics, AdRoll, Stripe и т. д.
Наша партнерская программа Kinsta — еще один пример. 60-дневный файл cookie размещается в браузере пользователя, когда он нажимает на партнерскую ссылку. Это гарантирует, что реферер получит надлежащий кредит, даже если человек закрыл и снова открыл свой браузер несколько раз.
Как WordPress Core использует файлы cookie
Когда мы говорим о ядре WordPress, мы просто имеем в виду файлы, которые составляют проект с открытым исходным кодом, до установки каких-либо сторонних плагинов или тем. Это WordPress в его естественном состоянии, как мы любим его называть.
Теперь, когда вы знаете основы того, что такое файлы cookie и их типы, давайте посмотрим, почему и как ядро WordPress использует их, чтобы все это волшебство происходило за кулисами. Забавный факт: первоначально слово cookie произошло от термина «волшебное печенье».
Ядро WordPress использует файлы cookie для двух разных целей:
1. Файлы cookie для входа
Файлы cookie для входа содержат данные аутентификации и используются, когда пользователь входит в панель администрирования WordPress. В соответствии с Кодексом WordPress устанавливается несколько разных файлов cookie сеанса:
- При входе в систему WordPress использует файл cookie
wordpress_[hash]
для хранения данных аутентификации (ограничено областью/wp-admin/
). - После входа в систему WordPress устанавливает
wordpress_logged_in_[хеш]
файл cookie. Это указывает, когда вы вошли в систему и кто вы.
Когда вы пытаетесь получить доступ к серверной части вашего сайта WordPress, выполняется проверка, чтобы убедиться, что два вышеуказанных файла cookie существуют и срок их действия не истек. Это то, что позволяет вам волшебным образом обойти экран wp-login.php
. 😉
WordPress также устанавливает файлы cookie wp-settings-{time}-[UID]
. Идентификатор — это ваш идентификатор пользователя из таблицы базы данных пользователей WordPress. Здесь хранятся настройки личного кабинета и интерфейса администратора.
2.
Файлы cookie комментариевПо умолчанию файлы cookie устанавливаются, когда кто-то комментирует сообщение в блоге (срок действия 347 дней). Это делается для того, чтобы, если они вернутся позже, им не нужно было заполнять всю информацию заново. Сохраняются следующие три файла cookie:
-
comment_author_[хэш]
-
comment_author_email_[хэш]
-
comment_author_url_[хэш]
Однако в связи с недавними изменениями в политике конфиденциальности, связанными с GDPR, в ядре WordPress были введены новые инструменты, позволяющие пользователям разрешать установку этих файлов cookie. Этот параметр, если он еще не установлен, можно включить в разделе «Настройки → Обсуждение» в панели администратора WordPress. Установите флажок «Показать флажок согласия на использование файлов cookie для комментариев». Популярный плагин Akismet также позволяет отображать уведомление о конфиденциальности.
как комментировать использование файлов cookieКак сторонние плагины и темы WordPress используют файлы cookie
Точно так же, как WordPress использует файлы cookie для определенных функций, сторонние плагины и темы, которые вы устанавливаете, также устанавливают файлы cookie. Большинство из них используют комбинацию файлов cookie браузера и строк базы данных , хранящихся в таблице wp_options
или в собственной пользовательской таблице. Это потому, что WordPress не имеет состояния.
Приложение без сохранения состояния — это прикладная программа, которая не сохраняет данные клиента, сгенерированные в одном сеансе, для использования в следующем сеансе с этим клиентом. Каждый сеанс выполняется так, как если бы это был первый раз, и ответы не зависят от данных предыдущего сеанса. – ТехТарджет
В связи с новыми законами о конфиденциальности как никогда важно понимать, какие файлы cookie устанавливаются и предоставляют ли они возможность подписаться вашим посетителям. Совет: не все файлы cookie требуют согласия. Прочтите наш подробный пост о GDPR, чтобы лучше понять новые требования.
Вот лишь несколько примеров того, для чего используются файлы cookie:
- Если у вас есть всплывающее окно на вашем сайте WordPress, и посетитель закрывает его, это обычно устанавливает файл cookie, чтобы он не т вернуться снова.
- Товары добавлены в корзину на вашем сайте электронной коммерции . Файл cookie сохраняется, чтобы в корзине оставались ваши продукты, пока вы продолжаете просматривать сайт.
- Функции IP-геолокации могут хранить IP-адрес и координаты широты/долготы посетителя, просматривающего сайт. Обычно это используется для отображения определенного контента в определенном регионе или, возможно, даже для перенаправления пользователя на другой дочерний сайт.
- Отслеживание активности по кликам с помощью сокращателя ссылок, такого как плагин PrettyLinks.
- Плагин новостной рассылки может устанавливать cookie для пользователей, если они уже подписались, это дает возможность полностью скрыть окно новостной рассылки.
По сути, любое действие или подписка на сайте WordPress, как правило, включает установку файла cookie в браузере за кулисами. Целью этого, конечно же, является попытка помочь улучшить работу браузера или предоставить дополнительные функции посредством проверки.
Вот все, что вам нужно знать о WordPress и файлах cookie. И мы не имеем в виду вкусные шоколадные чипсы. 🍪Нажмите, чтобы твитнутьФайлы cookie WooCommerce
Плагины электронной коммерции, такие как WooCommerce, обычно имеют свои собственные дополнительные файлы cookie, которые они устанавливают, чтобы покупатели могли легко добавлять товары в свою корзину, сохранять их на потом при оформлении заказа, а также входить и выходить из своей учетной записи.
Чтобы отслеживать данные корзины, WooCommerce устанавливает следующие три файла cookie (личная информация не хранится в файлах cookie):
-
woocommerce_cart_hash
-
woocommerce_items_in_cart
-
wp_woocommerce_session_
Первые два файла cookie содержат информацию о корзине и просто помогают WooCommerce узнать об изменении данных корзины. Третий файл cookie wp_woocommerce_session_
содержит уникальный код для каждого клиента, который соответствует записи в пользовательской таблице wp_woocommerce_sessions
в базе данных.
Данные wp_commerce_session_
ранее хранились в wp_options
, но был перемещен в собственную настраиваемую таблицу в WooCommerce 2.5, когда они представили новый обработчик сеанса. Это должно было улучшить производительность, масштабируемость и управление сеансами. В противном случае вы быстро получите раздутую таблицу wp_options, которую вам придется очищать.
Файлы cookie Easy Digital Downloads
Easy Digital Downloads по умолчанию использует WP_Session, который представляет собой комбинацию файлов cookie браузера и строк базы данных, хранящихся в таблице wp_options
. Ниже приведен файл cookie, который он устанавливает:
-
edd_items_in_cart
Файлы cookie и кэширование WordPress
Когда дело доходит до кеша WordPress, здесь все становится сложнее. Кэширование — это, по сути, процесс хранения ресурсов из одного запроса и повторного использования этих ресурсов для последующих запросов. По сути, это сокращает объем работы, необходимой для создания просмотра страницы. Хотя это отлично подходит для производительности, это вызывает проблемы с файлами cookie.
Разверните свое приложение в Kinsta — начните с
$20 Кредит сейчас.Запустите свои приложения Node.js, Python, Go, PHP, Ruby, Java и Scala (или почти все, что угодно, если вы используете свои собственные файлы Docker) в три простых шага!
Разверните сейчас и получите скидку 20 долларов на
Почему? Потому что файлы cookie предназначены для выполнения определенных действий, например, для заполнения корзины покупок, когда вы просматриваете сайт WooCommerce. Однако, если страница обслуживается из кеша, ни PHP, ни база данных ничего не делают, сервер просто обслуживает статическую копию страницы.
Так что ты можешь сделать?
1. Использовать JavaScript
Первый вариант — использовать JavaScript и динамически обновлять содержимое на странице. По сути, у вас есть заполнители HTML и вы используете JavaScript для получения информации через вызов API или ajax.
В качестве примера можно привести загрузку списка сообщений на боковой панели WordPress с помощью JavaScript, чтобы получить список сообщений через wp-api и затем отобразить их на боковой панели. В этом случае вы можете обновить список сообщений, не очищая страницу от кеша, поскольку данные генерируются динамически.
Однако это не идеально, всегда лучше кэшировать, если это возможно, с точки зрения производительности. Но если вам нужно, чтобы какая-то часть контента оставалась динамической, а сама страница могла оставаться статической (обслуживаемой из кеша), это один из способов сделать это — использовать JavaScript для динамического извлечения контента для этой части страницы через API/ajax. вызов. Однако, если вы не можете нанять разработчика WordPress для создания собственного решения JavaScript или расширения плагина, этот вариант обычно нецелесообразен.
2. Используйте вызовы Admin-Ajax
Admin-ajax.php
не может быть кэширован, поэтому вы можете использовать вызовы admin-ajax. Хорошим примером этого является плагин No Cache AJAX Widgets. Он выполняет вызовы admin-ajax, поэтому ему не нужно беспокоиться о конфликте с решениями кэширования на уровне сервера или сторонними решениями.
Однако, как и в случае с JavaScript, этот путь обычно невозможен для обычного пользователя. Это также может привести к другим проблемам с производительностью, таким как интенсивное использование admin-ajax и большое количество некэшированных запросов.
3. Исключить страницы из кэша (при наличии файла cookie)
Если вы не можете пойти по маршруту JavaScript или admin-ajax, лучше всего исключить страницы из кэширования при наличии определенного файла cookie. Обычно это то, что мы рекомендуем, особенно тем, у кого есть высокодинамичные сайты, такие как WooCommerce и Easy Digital Downloads.
В Kinsta некоторые страницы WooCommerce и Easy Digital Downloads, такие как корзина, моя учетная запись и проверка, автоматически исключаются из кэширования. Существует правило на уровне сервера, чтобы пользователи автоматически обходили кеш, когда 9Обнаружен файл cookie 0072 woocommerce_items_in_cart или edd_items_in_cart
, чтобы обеспечить плавный и синхронизированный процесс оформления заказа.
Мы также прослушиваем связанные файлы cookie для входа в систему и устанавливаем кеш для обхода, когда мы обнаруживаем, что кто-то вошел в WordPress. Предотвращает случайное кэширование внутренней панели мониторинга.
По умолчанию мы не исключаем файл cookie wp_woocommerce_session_
из кэширования. По нашему опыту, большинство сайтов WooCommerce не имеют проблем. Это также повышает производительность за счет увеличения коэффициента попаданий в кеш при использовании меньшего количества рабочих процессов PHP.
Однако из-за того, что существует множество различных тем WordPress и конфигураций плагинов, мы можем исключить файл cookie wp_woocommerce_session_
из кеша, если это необходимо. Просто обратитесь в нашу службу поддержки. В результате, как только пользователь добавляет продукт в свою корзину, все последующие запросы не будут обслуживаться из кеша, что увеличивает использование рабочих процессов PHP.
Если вам нужна пользовательская страница, исключенная из кеша, не стесняйтесь обращаться в нашу службу поддержки. Опять же, вы должны будьте осторожны с исключениями . Слишком большое количество некэшированных страниц может серьезно снизить производительность. Ознакомьтесь с нашими советами по размещению членских сайтов WordPress.
Как просмотреть и удалить файлы cookie
Просмотреть и удалить файлы cookie на веб-сайте очень просто. Чтобы узнать, какие файлы cookie установлены на конкретном сайте, перейдите на этот сайт и щелкните значок маленького замка вверху. Затем нажмите «Файлы cookie».
Используемые файлы cookie Затем перейдите к папке этого веб-сайта. В приведенном ниже примере вы можете видеть, что у нас установлено несколько файлов cookie WooCommerce, а также wordpress_logged_in_[хеш]
файл cookie. Вы также можете увидеть время истечения срока действия и то, является ли это постоянным файлом cookie или файлом cookie сеанса (когда сеанс просмотра заканчивается).
Чтобы удалить файл cookie, просто щелкните отдельный файл cookie и нажмите кнопку «Удалить». Вы также можете сделать это на уровне папки или в Chrome DevTools.
Очистка файлов cookie также может помочь вам исправить ошибку 304.
Кроме того, вы можете выполнить поиск или удалить все файлы cookie в своем браузере.
GDPR — это новый закон о конфиденциальности, вступивший в силу 25 мая 2018 года. Он был разработан, чтобы вернуть гражданам контроль над своими личными данными. Мы настоятельно рекомендуем прочитать наш подробный пост: подробности о соблюдении GDPR, если вы еще этого не сделали. Это одна тема, которую нельзя обобщить в абзаце!
Вот пример изменения, которое мы внесли в Kinsta, чтобы соответствовать новому закону. Когда вы впервые посещаете наш сайт, вы, возможно, уже видели его, вас встречает подсказка «Принять файлы cookie» в нижней части экрана. Это связано с тем, что теперь мы по закону обязаны предоставить пользователям возможность подписаться и отказаться от установки файлов cookie. Прошли те времена, когда вы просто запускали все, что хотите, не информируя пользователей о сборе данных.
Если вы нажмете «Принять файлы cookie», для пользователя будут установлены все файлы cookie. Если вы нажмете «Настройки файлов cookie», теперь мы предоставим возможность подписаться и отказаться от любых файлов cookie, которые вы хотите.
Настройки cookieДовольно изящно, верно? Наше решение для файлов cookie было создано нашими разработчиками собственными силами, но вот несколько полезных плагинов GDPR для WordPress, которые могут помочь вам сделать что-то подобное. Опять же, файлы cookie — это лишь небольшая часть полного соответствия GDPR.
Сессии PHP
Сеансы PHP являются альтернативой стандартному подходу к файлам cookie. Это все еще файл cookie, но он называется PHPSESSID и обычно хранится в каталоге /tmp/
на самом веб-сервере. Способ, которым сервер знает, как связать данный сеанс с данным запросом, заключается в том, что он также хранится в файле cookie HTTP.
Это также можно увидеть под заголовком HTTP для сайта.
Заголовок HTTP устанавливает cookie PHPSESSIDСеанс PHP очень похож на обычный сеанс, который заканчивается, когда пользователь закрывает свой браузер.
Все проблемы с сеансами PHP сводятся к проблемам с производительностью и кэшированием. Информация, хранящаяся в файле cookie браузера, должна возвращаться туда и обратно с каждым запросом, чтобы сервер знал, кто является пользователем. Это означает, что для сайтов, использующих PHPSESSID, хост должен установить PHPSESSID для обхода кеша. Однако в результате в 100 % случаев для обхода PHPSESSID необходимо установить, потому что, в отличие от wordpress_logged_in
, PHPSESSID устанавливается при каждом отдельном запросе PHP.
Итак, представьте, что wordpress_logged_in
должен быть установлен в 100% случаев, чтобы функция входа в систему работала. Это означает, что даже вышедшие из системы пользователи должны иметь файл cookie, и он должен быть уникальным для них. Представьте, что это необходимо для того, чтобы система входа в WordPress работала. В этом сценарии каждый просмотр страницы должен был бы обходить кеш, чтобы файл cookie wordpress_logged_in
был правильно установлен как для вошедших, так и для вышедших из системы пользователей.
Это проблема с использованием PHPSESSID. Поскольку он генерируется при каждом отдельном запросе PHP, если сайт использует файлы cookie PHPSESSID, хост должен настроить PHPSESSID на обход кеша в 100 % случаев. В противном случае идентификатор PHPSESSID оказывается в кэше, что приводит к нарушению всех функций, которые от него зависят.
Мы не рекомендуем использовать сеансы PHP, и они обычно не работают в нашей среде Kinsta. Сеансы PHP также имеют другие последствия для безопасности, которые следует учитывать.
Если вы видите код, использующий session_start
на вашем сайте, это означает, что он использует сеансы PHP.
Многие разработчики плагинов и тем перешли на использование комбинации файлов cookie браузера и строк базы данных (либо в таблице wp_options
, либо в их собственной пользовательской таблице). Если вам нужны данные сеанса, это лучший подход.
Не стесняйтесь обращаться в нашу службу поддержки, если у вас есть дополнительные вопросы относительно сеансов PHP.
Резюме
Надеюсь, теперь вы знаете немного больше о том, как работают файлы cookie WordPress и сеансы PHP, чем раньше. В настоящее время файлы cookie — это то, что заставляет мир вращаться, и они важны практически для всего, что происходит на сайте WordPress. От удержания нас в системе до обеспечения бесперебойной работы корзины покупок и даже обеспечения того, чтобы всплывающее окно оставалось закрытым.
У вас есть другие вопросы о файлах cookie? 🍪 Дайте нам знать ниже в комментариях.
Получите все свои приложения, базы данных и сайты WordPress онлайн и под одной крышей. Наша многофункциональная высокопроизводительная облачная платформа включает в себя:
- Простая настройка и управление на панели управления MyKinsta
- Экспертная поддержка 24/7
- Лучшее оборудование и сеть Google Cloud Platform на базе Kubernetes для максимальной масштабируемости
- Интеграция Cloudflare корпоративного уровня для скорости и безопасности
- Глобальный охват аудитории благодаря 35 центрам обработки данных и 275 точкам присутствия по всему миру
Протестируйте сами со скидкой 20 долларов на первый месяц хостинга приложений или хостинга баз данных. Ознакомьтесь с нашими планами или поговорите с отделом продаж, чтобы найти наиболее подходящий вариант.
Меры безопасности сеанса PHP для обеспечения безопасности веб-сайтов
Follow @Cloudways
Протокол передачи гипертекста начинался как протокол без сохранения состояния. Это означает, что каждый запрос к серверу является автономным, он содержит весь контекст, который необходим серверу для обслуживания запрошенной веб-страницы. Каждое сообщение, которое клиент отправляет на сервер, может быть обработано само по себе — сервер не сохраняет ни состояние, ни информацию о соединении.
Веб-приложениям нужен способ сохранения контекста посетителя — от вошедшего в систему удостоверения пользователя, корзины покупок в магазинах электронной коммерции до долгосрочных данных, таких как история покупок или история чатов в приложениях социальных сетей.
Вот почему для HTTP и всех приложений, построенных на его основе, было необходимо найти решения для управления этим присущим HTTP отсутствием состояния. Основное решение — файлы cookie.
PHP, возможно, является наиболее часто используемым языком программирования для Интернета (w3techs дает ему почти 80%), и у него есть собственное решение для этого — PHP-сессии. В этой статье мы опишем механизмы сеансов PHP, рассмотрим безопасность сеанса PHP и способы защиты файлов cookie сеанса PHP.
Мы увидим, каковы потенциальные уязвимости и лучшие практики безопасности сеанса php.
Защитите свой веб-сайт с помощью мер безопасности сеанса PHP
- HTTP и состояние
- сеансов PHP
- Использование сеансов в PHP
- Проблемы с безопасностью сеансов PHP
- Что такое атака с перехватом сеанса?
- типов атак с перехватом сеанса
- XSS или межсайтовый скриптинг
- Сессия Sidejacking
- Фиксация сеанса
- Что может сделать злоумышленник с успешно захваченным сеансом?
- Рекомендации по безопасности сеансов PHP
- Атака XSS (межсайтовый скриптинг)
- Сессия Sidejacking
- Фиксация сеанса
- Прогноз сеанса
- Заключение
HTTP и состояние
HTTP с самого начала стал расширяемым за счет своих заголовков. Это означает, что функциональность может быть добавлена к HTTP-запросам и ответам с помощью определяемых пользователем заголовков.
Заголовки — это поля в каждом запросе и ответе, которые могут содержать различные фрагменты метаданных.
Файлы cookie были опубликованы IETF в качестве дополнения к стандарту HTTP в 1997 году, и с тех пор спецификация была усовершенствована и окончательно определена в RFC 6265 под названием Механизм управления состоянием HTTP .
Файлы cookie определены IETF как механизм, состоящий из полей заголовка HTTP, которые могут использоваться серверами для хранения фрагментов данных (состояния) в клиентах HTTP. Это позволяет серверу сохранять контекст с отслеживанием состояния, называемый сеансом, для нескольких HTTP-запросов.
Браузер пользователя (клиент) затем отправляет эти файлы cookie на сервер при последующих запросах, позволяя серверу реконструировать состояния, такие как путь покупателя, корзина покупок или учетная запись в социальной сети.
Мы можем различать файлы cookie сеанса и постоянные файлы cookie. Сессионные куки-файлы являются временными — они сохраняются только в течение этого конкретного сеанса браузера. Они живут в памяти браузера. Поскольку срок их действия истекает при закрытии текущего экземпляра браузера, у них нет срока действия.
Постоянные файлы cookie имеют срок действия, они предназначены для хранения в течение определенного периода времени.
Они используются для таких вещей, как персонализация взаимодействия с пользователем, управление сессиями, включая состояние входа/выхода пользователей, корзины и отслеживание поведения пользователя.
Файлы cookie обычно хранят очень ограниченный объем данных (максимум 4096 байт на веб-сайт) и хранятся на компьютерах посетителей. Это делает файлы cookie ограниченными и небезопасными — их недостаточно для удовлетворения потребностей современных веб-сайтов в сеансах.
Защитите свои приложения в облаке
Cloudways предлагает двухфакторную аутентификацию, бесплатный SSL и более продвинутые функции безопасности на управляемых серверах, которые обеспечивают безопасность вашего приложения.
Свободный запуск
PHP Sessions
PHP как язык веб-программирования относится к прикладному уровню. PHP основан на файлах cookie HTTP, чтобы обеспечить механизм для поддержки контекста в нескольких запросах. Для этого он объединяет настраиваемый заголовок файла cookie со своим собственным классом обработчика сеанса:
9.0419 SessionHandler реализует SessionHandlerInterface , SessionIdInterface { /* Методы */ публичное закрытие ( ): bool public create_sid(): строка общественное уничтожение (строка $id): bool общедоступный gc ( int $ max_lifetime ): int | bool public open (строка $path, строка $name): bool общедоступное чтение (строка $id): строка общедоступная запись (строка $id, строка $data): bool }Этот механизм можно расширить или полностью переписать, унаследовав класс SessionHandler или реализовав SessionHandlerInterface.
В PHP сеансы по умолчанию сохраняются в виде файлов на сервере. Файлы несут имена соответствующих идентификаторов сеансов. Когда сеанс инициируется, PHP устанавливает файл cookie PHPSESSID с идентификатором сеанса. Позже, когда браузер посетителя возвращает этот файл cookie по каждому запросу, сервер связывает его с данными сеанса в файле, относящемся к этому сеансу. Результатом является непрерывное состояние сеанса на нескольких страницах веб-сайта.
Использование сеансов в PHP
Сеанс в PHP можно запустить вызовом функции session_start() . Эта функция либо запускает новый сеанс, либо восстанавливает существующий сеанс, переданный серверу в файле cookie, либо в параметрах запроса POST или GET. Затем суперглобальный массив $_SESSION используется для установки или получения переменных в сеансе.
Если мы затем хотим использовать переменные сеанса на других страницах того же веб-сайта, другой документ PHP должен использовать session_start() . Это сделает переменных $_SESSION , которые могли быть установлены на других веб-страницах/документах, доступными на текущей.
session_close() фиксирует изменения в $_SESSION на диске
session_destroy() Функция уничтожит все данные сеанса. Чтобы полностью удалить сеанс, также необходимо сбросить идентификатор сеанса и явно удалить файл cookie сеанса. Помимо этих основ, PHP имеет множество других функций для обработки сеансов.
Функциональность, которую пытаются обеспечить сеансы PHP, — постоянные данные о посещениях страниц веб-сайта — незаменима для современных веб-сайтов. Однако реализация сеансов PHP является предметом разногласий.
Поскольку данные сеанса в PHP по умолчанию записываются в файл на сервере, а файл блокируется во время выполнения скрипта, это может создавать проблемы с точки зрения производительности и масштабирования.
Сеансы PHP также создают проблемы для обычного механизма кэширования — кэширование страниц с набором файлов cookie PHPSESSID может серьезно повредить веб-сайт, в то время как обход кеша для страниц с PHPSESSID будет означать обход кеша на всем веб-сайте.
А еще есть проблемы с безопасностью.
Вопросы безопасности сеансов PHP
Сеансы PHP — это шаг вперед в отношении безопасности по сравнению с системой, в которой все данные сеанса хранятся в файлах cookie. Файл cookie PHPSESSID просто хранит идентификатор ссылки для файла сеанса, который находится на сервере.
Настройка PHP по умолчанию для пути для сохранения файлов сеанса, который мы можем найти в файлах конфигурации php.ini: session.save_path = «/tmp» . Это означает, что файлы сеанса могут быть скомпрометированы другими пользователями.
Эта проблема вызывает особую тревогу, если вспомнить, что большинство веб-сайтов на PHP работают на общих серверах с несколькими арендаторами.
Наиболее распространенным из всех эксплойтов сеанса является Session Hijacking.
Что такое атака с перехватом сеанса?
Перехват сеанса происходит, когда злоумышленник получает незаконный доступ к сеансу другого пользователя. Злоумышленник сначала получит идентификатор сеанса, принадлежащий другому пользователю. Затем он будет использовать этот идентификатор для получения полного доступа к сеансу другого пользователя. Идентификатора сеанса достаточно, чтобы сервер предоставил доступ к соответствующей учетной записи.
Теоретически идентификатор сеанса может быть получен путем предсказания или угадывания (грубая сила), но наиболее вероятным способом является похищение идентификатора сеанса. И атака полным перебором, и предсказание идентификатора происходят гораздо реже.
Существует несколько векторов, по которым злоумышленник может получить доступ к идентификатору сеанса пользователя.
Типы атак с перехватом сеанса
Перехват сеанса может происходить разными способами – здесь мы упомянем только наиболее известные:
- XSS или межсайтовый скриптинг — это атака, которая происходит, когда третьей стороне удается внедрить javascript в тело веб-сайта, который посещает жертва. Предположим, что веб-сайт XY использует переменные GET и не очищает их должным образом. Злоумышленник может использовать javascript в запросе GET и внедрить его в тело веб-страницы, получив тот же уровень доступа, что и собственный javascript веб-сайта. Например, он может получить содержимое файла cookie PHPSESSID, а затем отправить его злоумышленнику.
- Session Sidejacking — этот тип атаки происходит с вектором атаки «человек посередине» — в ситуациях, когда злоумышленник находится между источником и получателем трафика. Злоумышленник будет прослушивать запросы и ответы, и, если трафик не зашифрован, он может получить идентификатор сеанса.
- Исправление сеанса происходит с уязвимыми веб-приложениями, которые не настаивают на том, чтобы всегда устанавливать новый идентификатор сеанса при аутентификации пользователя, а вместо этого принимают существующий идентификатор сеанса, когда он существует. В этом типе атаки злоумышленник подделает действительный, но неиспользованный идентификатор сеанса, а затем с помощью различных схем заставит действительного пользователя аутентифицироваться с использованием этого идентификатора. После этого, завладев идентификатором аутентифицированного пользователя, злоумышленник получает доступ к сеансу пользователя.
- Предсказание сеанса — при этом типе атаки злоумышленник обычно имеет некоторое представление о том, как приложение генерирует идентификаторы сеанса, и затем пытается угадать идентификаторы других пользователей, используя тот же метод. Здесь большую роль играет случайность генерации Session ID.
Что может сделать злоумышленник с успешно захваченным сеансом?
Как только злоумышленник получит доступ к сеансу, принадлежащему законному пользователю, сервер предоставит ему все полномочия, которыми обладает первоначальный пользователь. Таким образом, идентификатор сеанса можно уподобить ключу, который предоставляет его владельцу доступ к дому, независимо от того, был он владельцем дома или нет.
Эта атака часто будет направлена на пользователей и сеансы с административным доступом, поэтому в этих случаях злоумышленник получит административные права на скомпрометированном веб-сайте.
Рекомендации по безопасности сеансов PHP и важность PHP
session.cookie_secure флагПрежде чем перейти к различным мерам, которые мы можем предпринять для предотвращения использования наших сеансов злоумышленниками, важно сказать, что уязвимости, связанные с сеансами PHP, не что-то конкретное для самого языка. Они не являются неотъемлемым недостатком PHP — другие технологии требуют аналогичных мер для смягчения тех же векторов атаки.
Итак, какие меры здравого смысла мы можем предпринять, чтобы смягчить атаки перехвата сеанса?
- Атака XSS (межсайтовый скриптинг) — защита от атак этого типа не зависит от сеанса. Веб-сайт должен предотвращать выполнение любого пользовательского ввода в браузере посетителя. Это просто означает, что любой пользовательский ввод через формы или параметры GET или что-то еще должен быть очищен перед его использованием. Это общая мера безопасности для веб-приложений от этого и других типов атак (например, SQL-инъекций). Две основные функции в PHP, используемые для очистки строк, — это htmlspecialchars() и strip_tags(). htmlspecialchars() преобразует специальные символы в объекты html, а strip_tags() просто удалит все теги HTML, включая тег