Ошибки работы с PHP сессиями в Unix/Linux
Ошибки работы с PHP сессиями в Unix/Linux
Хочу описать статью с возможными ошибками работы PHP и сессиями в Unix/Linux. Думаю многие сталкиваются и будет полезно знать как решать ту, или иную ошибку.
Обновлял заббикс и после его обновления, перестал корректно работать, посмотрел лог и увидел:
2017/12/08 21:15:48 [error] 40014#40014: *395 FastCGI sent in stderr: "PHP message: PHP Warning: require_once(/etc/zabbix/web/maintenance.inc.php): failed to open stream: Permission denied in /usr/share/zabbix/include/classes/core/ZBase.php on line 269
-=== Ошибка 1 ===-
Можно увидить следующую ошибку:
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.
Возникла у меня при установке phpmyadmin.
Так же, если имеется cPanel, может возникнуть такая же ошибка, я описывал решение в моей статье:
ошибка в phpMyAdmin «Cannot start session without errors»
-=== Ошибка 2 ===-
При работе с апачем, я получил:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_eqbchncji8kj22f0iqa9g3v7u2, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/httpdocs/index.php on line 6 Warning: Unknown: open(/var/lib/php/session/sess_eqbchncji8kj22f0iqa9g3v7u2, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0
-=== Ошибка 3 ===-
Получил еще ошибку:
FastCGI sent in stderr: “PHP message: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0” while reading upstream, client: 37.***.***.56, server: rtfm.co.ua, request: “POST /wp-admin/admin-ajax.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9009”, host: “rtfm.co.ua”, referrer: “http://linux-notes.org/wp-admin/post.php?post=5496&action=edit&message=10”
Другие ошибки я буду добавлять по мере их возникновения.
Решения ошибок работы с PHP сессиями в Unix/Linux
$ php -i |grep save_path session.save_path => /var/lib/php/session => /var/lib/php/session
Как видно у меня этот путь рассположен в /var/lib/php/session директории.
Проверим права на данную директорию:
# ls -alh /var/lib/php/session
Смотрим от какого юзера идет выполнение php кода:
# ps aux |grep php-fpm
PS: Или, можно зайти в ваш пул php-fpm и найти пользователя от которого он запущен!
Решение довольно примитивное. Для начала, стоит создать папку под использующие сессии (если ее нет еще) и выставить права:
# mkdir /var/lib/php/session # chmod 1777 /var/lib/php/session
И так же, выставляем владельца и группу:
# chown root:www /var/lib/php/session # chown -R www: /var/cache/nginx
ИЛИ:
# chmod o+rw /var/lib/php/session
Потом, открываем ваш php. ini и находим строку:
;session.save_path = "/tmp"
И нужно выполнить расскоменчивание данной строки.
PS: Возможно, нужно будет выставить права и владельца!
Если вы используете выделенные пулы под свои php- проекты, то стоит поискать данную строку в:
# grep -lR 'php_value' /etc/php-fpm.d
Если покажет файлы, то стоит посмотреть привести к:
[...] php_value[session.save_handler] = files php_value[session.save_path] = /var/lib/php/session [...]
Перезапускаем php-fpm службу:
# service php-fpm restart
Для апача, следуюет указать следующие строки:
php_value session.save_handler "files" php_value session.save_path "/var/lib/php/session"
а поиск файла можно сделать так:
# grep -lR 'php_value' /etc/
И тоже, выполнить перезапуск службы:
# service httpd restart
Вот и все решение! А у меня на этом статья «Ошибки работы с PHP сессиями в Unix/Linux» завершена.
Установка phpmyadmin. Error during session start | PHPClub
STELIO
Новичок
- #1
Привет. Не могу установить phpmyadmin. Пишет «Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.». В браузере куки включены. Вроде php.ini и httpd.conf правильно настроил. Есть Сэнсэй, кто подскажет в чем проблема? php.ini http://hastebin.com/ojofaveriz.vhdl httpd.conf http://hastebin.com/egebefagah.apache
С.

Продвинутый новичок
- #2
www.adminer.org
STELIO
Новичок
- #3
Проблема была в php.
С.
Продвинутый новичок
-
- #4
phpmyadmin — это смердящий динозавр из прошлого столетия. Его палкой трогать противно, не то что php.ini под него править.
AnrDaemon
Продвинутый новичок
- #5
Предложите адекватную замену.
С.
Продвинутый новичок
- #6
AnrDaemon написал(а):
Предложите адекватную замену.
Нажмите для раскрытия…
Тему не читай, комментарии пиши.
fixxxer
К.О.
AnrDaemon написал(а):
Предложите адекватную замену.
![]()
Нажмите для раскрытия…
Sequel Pro, SQLYog итд
c0dex
web.dev 2002-…
- #8
fixxxer, проприетарщина же и макосьовщина)
был неплохой workbench раньше, как сейчас он я хз
fixxxer
К.О.
- #9
c0dex, макосовщина как раз опенсорсная (желающие могут портировать UI на какой-нибудь Qt, хе-хе). Хорошего OSS кроссплатформенного решения я не знаю, но, впрочем, в 99% случаев мне хватает обычного консольного клиента, Sequel Pro в основном использую для ознакомления с какой-то базой неизвестной мне структуры.
флоппик
promotor fidei
- #10
JetBrains 0xBDE же
c0dex
web.dev 2002-…
- #11
fixxxer, макосьовщина это макосовщина, и потому нафик) ты workbench смотрел?
флоппик
promotor fidei
- #12
Воркбенч — тормозное убогое говно, зато умеет почти все для MySQL
c0dex
web.

- #13
флоппик, пока юзаю у меня тормозов не замечено.
fixxxer
К.О.
- #14
c0dex, он какой-то неудобный и страшный. По крайней мере 2 года назад таким был, судя по скринам, мало что изменилось. Я когда на линукс-десктопе работал, SQLYog в wine запускал, и то удобнее =)
c0dex
web.dev 2002-…
- #15
ну не знаю, сейчас он выглядит очень даже привлекательно, это на убунте 14.04. На дебиане не ставил.
AnrDaemon
Продвинутый новичок
- #16
флоппик написал(а):
Воркбенч — тормозное убогое говно, зато умеет почти все для MySQL
Нажмите для раскрытия.
..
Вынужден согласиться с обоими утверждениями.
сессий WordPress и PHP | PHP на Pantheon
Узнайте больше о поведении сеансов WordPress и PHP.
Обсудить на нашем форуме Обсудить в SlackРедактировать эту страницу на GitHub | Сообщить о проблеме с этим документом
В этом разделе содержится информация о сеансах WordPress и PHP.
WordPress Core не использует сеансы. Все «состояние пользователя» управляется с помощью файлов cookie. Это ключевое дизайнерское решение.
Однако некоторые плагины или темы будут использовать session_start()
или PHP $_SESSION
superglobal. Вы должны использовать поддерживаемый Pantheon плагин WordPress Native PHP Sessions, чтобы использовать PHP Sessions в Pantheon.
Предупреждение
Этот подключаемый модуль не решит все проблемы и ошибки, связанные с $_SESSION
, из-за различий в реализации. Если вы используете этот плагин и у вас все еще есть проблемы, измените код в своей теме или плагине, который вызывает
$_SESSION
, чтобы удалить эту функцию или использовать альтернативу.
Перед установкой собственных сеансов PHP WordPress вы можете увидеть следующую ошибку:
Предупреждение: session_start(): функции сеанса пользователя не определены
Плагины с кодом, использующим сеанс, полагаются на диспетчер сеансов PHP по умолчанию, который является локальный диск. Pantheon не поддерживает это, потому что это не будет работать должным образом в нашей распределенной среде.
Varnish или кэширование не работают, когда включен плагин или тема, использующая $_SESSIONS
Из-за того, как работает кэширование и сеансы, для правильной работы сеансы должны быть не кэшированы, а использование кэшированного содержимого невозможно при наличии сеансов. Лучше всего использовать решение на основе файлов cookie, чтобы избежать падения производительности из-за некэшированных страниц сеанса.
Признаки этой проблемы можно обнаружить, проверив заголовок. Файл cookie сеанса всегда устанавливается при каждой загрузке страницы:
Set-Cookie: SESS1234XXXXXXXXXXXXXX path=/; домен=.example.pantheonsite.io; HttpOnly
Лучший способ определить, какой плагин или тема препятствует кэшированию, — это найти в коде плагина и темы вашего сайта функцию session_start()
PHP:
cd wp-content grep -rnw . -e 'session_start'
Кроме того, вы можете проверить заголовки, используя curl -sI example.com
после каждого из следующих шагов, пока не определите, какой компонент нарушает кэш:
-
Используйте тему по умолчанию например) и проверьте файл cookie.
-
Отключите плагины один за другим, чтобы увидеть, не нарушает ли плагин кэш. Не забывайте очищать кеш панели инструментов Pantheon каждый раз, когда отключаете плагин. Виновником, скорее всего, является первый отключенный плагин, который снова заставляет кэш работать.
Примечание. Если у вас есть локальная копия вашего сайта, вы можете найти в ней плагины, использующие
session_start()
или$_SESSIONS
, и сначала начать отключать их. -
Удалите (временно) обязательные к использованию сторонние плагины и оставьте только
Pantheon
иWP Native PHP Sessions
, чтобы проверить, не нарушает ли кеш сторонний обязательный плагин или вставной плагин. На месте не должно быть вставок.
Установите плагин WordPress Native PHP Sessions
Установите плагин WordPress Native PHP Sessions, если $_SESSIONs
необходимы для вашего приложения:
-
Установите режим подключения SFTP для среды Dev или Multidev через панель управления Pantheon или с конечной:
терминальное соединение: установить
. sftp -
Установить и активировать собственные PHP-сессии WordPress из панели управления WordPress среды Dev или Multidev (
/wp-admin/plugin-install.
) или с помощью Terminus:php?tab=search&s =wp+native-php-sessions
terminus wp
. -- установка плагина wp-native-php-sessions --activate -
Зафиксируйте свои изменения через панель управления сайтом или с конечной:
terminus env:commit --message "Добавление плагина php native session" --
. (Дополнительные параметры для этой команды)
-
Объедините свои изменения в Dev, если вы работаете над Multidev . termus env:deploy <сайт>.test —sync-content —updatedb —note=»Установить плагин WordPress Native PHP Sessions»
(дополнительные параметры для этой команды)
-
Активируйте плагин в панели инструментов WordPress в тестовой среде (
/wp-admin/plugins.php
) или с помощью Terminus:terminus wp
.test - - plugin активировать wp-native-php-sessions -
Разверните плагин в среде Live на панели управления сайтом или с помощью Terminus:
terminus env:deploy
. live --note="Install WordPress Native PHP Sessions плагин"
(Дополнительные параметры для этой команды)
-
Активируйте плагин в панели инструментов WordPress в среде Live (
/wp-admin/plugins.php
) или с помощью Terminus:terminus wp
.live - - плагин активирует wp-native-php-sessions
Для получения дополнительной информации см. Исправление проблем PHP-сессии WordPress в Pantheon с помощью скрипта.
Запуск сеанса для каждого пользователя является антишаблоном приложения. Обслуживание страниц пользователям с сеансами не может осуществляться из кэша, поэтому создание сеанса для каждого посетителя по своей сути делает ваше приложение немасштабируемым.
Наш плагин предоставляет экран администратора, чтобы увидеть, сколько сеансов было запущено. Вы также можете проверить заголовки, отправляемые вашим сайтом. Если вы открываете новое окно в режиме инкогнито и видите, что в ответ на запрос вашего сайта отправляется файл cookie PHPSESS
, значит, у вас слишком интенсивный код сеанса.
Пользователи командной строки могут использовать этот быстрый фрагмент для тестирования:
curl -Is https://www.getpantheon.com | grep PHPSESS|wc -l
Вы должны заменить URL своего сайта в примере, и желаемый результат будет «0» (ноль).
Если ваш сайт слишком агрессивно запускает сеансы, вам следует поискать в кодовой базе ссылки на session_start()
или $_SESSION
, чтобы увидеть, где это происходит, и разработать обходной путь. Если код находится в плагине сообщества, откройте задачу на WordPress.org, чтобы предупредить автора о проблеме и поделиться своим решением.
-
Требования WordPress PHP
-
Настройте файл wp-config.php
Меры безопасности сеанса 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 со своим собственным классом обработчика сеанса:
Этот механизм можно расширить или полностью переписать, унаследовав класс 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, включая тег