Cookie setting in php ini

Is session.cookie_secure in php.ini automatic?

in the php.ini file for my website, will that automatically turn all the php cookies to secure and httponly, or will I still need to put in true, true into parameter slots 6 and 7 in the cookie itself?

Tried testing it? Based on the naming, I think this only affects the session cookies used by php itself and not any «custom» set cookies.

@MrTux I’m not referring to ‘custom’ set cookies, just the standard php cookie, i.e. setcookie(‘name’,’value’,time,’/’,’mysite.com’,true,true)

@MrTux, Well, you’ve downvoted the question so no one else will bother with it, but you haven’t answered it.

I suppose it got downvoted because the question can be easily solved by using google and also the question isn’t really clear: What are parameter slots 6 and 7 ?

1 Answer 1

The answer is yes. Setting this in php.ini is enough (however, I only saw «True» as the setting used instead of «On»).

You can verify this by setting these values, restarting your webserver and accessing your site with a browser, e.g. Firefox. Then open «site information», and choose «security» tab and click on cookies. There you can see if it’s marked as secure.

Thank you. I did Google it many times as well as look in Stack, but the questions were all a little different and even php.net did not specifically state what I wanted, which was, a clear answer. You’ve also provided references so again, thank you. I’ll follow them up to find a fuller explanation. Lastly, thank you for taking the extra time after your initial comment.

This question is in a collective: a subcommunity defined by tags with relevant content and experts.

Источник

Настройка времени сессий в PHP

Обновлено: 08.04.2021 Опубликовано: 25.02.2018

Тематические термины: PHP, Веб-сервер, Cookie. От времени действия сессии зависит период работоспособности PHP-переменных $_SESSION, и как следствие, активности веб-приложений. Например, если пользователь авторизовался в системе, время в течении которого он может бездействовать без необходимости повторного ввода логина и пароля зависит от данного параметра. Существуют разные способы установки времени жизни сессий. Попробуем разобраться на примере операционной системы Linux.

Как узнать время жизни сессии

1. На сервере командой php

Данные значения — значение по умолчанию. cookie_lifetime => 0 говорит о действии файлов куки до закрытия браузера, если задать этому параметру определенное значение, сессия будет прерываться при активном сеансе, поэтому лучше ее оставлять в значении ноль.

2. C помощью php-функции ini_get

$maxlifetime = ini_get(«session.gc_maxlifetime»);
$cookielifetime = ini_get(«session.cookie_lifetime»);

echo $maxlifetime;
echo $cookielifetime;

Настройка сессий на веб-сервере

Выполняется путем настройки файла php.ini. Данный способ удобен, если мы являемся администратором веб-сервера, а также если есть гарантия, что общая настройка сессий не повлияет на работоспособность всех веб-приложений, работающих на данном сервере.

Открываем на редактирование php.ini. Его расположение зависит от сборки Linux. Точный путь можно посмотреть командой:

Теперь открываем сам файл:

* в моем случае каманда php -i | grep php.ini вернула данный путь.

В некоторых системах, например, Ubuntu или Debian для каждой среды обработки кода создается свой php.ini файл, а также для каждой версии PHP. Например, по пути /etc/php/7.4/fpm/php.ini находится файл для php-fpm для PHP версии 7.4. Нам необходимо учитывать данный факт, чтобы настроить нужный файл.

И редактируем следующие параметры:

session.gc_maxlifetime = 86400
session.cookie_lifetime = 0

* где параметр gc_maxlifetime указывает на временя в секундах, после прошествии которого данные могут быть удалены; cookie_lifetime — время жизни файлов cookies; 86400 — 24 часа в секундах.
* если параметру gc_maxlifetime задать значение 0, действие сессий будет бесконечным. Это, как правило, не стоит делать — приведет к падению производительности и безопасности сервера.

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

systemctl restart apache2 || systemctl restart httpd

* в версиях Linux без systemd используем команду service apache2 restart или service httpd restart.

Если используем FastCGI (PHP-FPM).

systemctl restart php7.4-fpm

* где 7.4 — версия используемого PHP.

Настройка через файл .htaccess

Данный файл позволяет веб-мастеру управлять некоторыми настройками веб-сервера. Для его редактирования нужен доступ к файлам сайта. Способ не сработает, если в качестве обработчика PHP используется не Apache, а, например, NGINX + PHP-FPM. Хотя, тут тоже есть способ (о нем будет ниже).

В файл .htaccess вносим следующее:

php_value session.gc_maxlifetime 86400
php_value session.cookie_lifetime 0

* как можно заметить, параметры те же, что при настройки через php.ini.

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

Открываем файл настройки веб-сервера, например, в php-fpm:

php_value[session.gc_maxlifetime] = 86400
php_value[session.cookie_lifetime] = 0

После перезапускаем сервис:

systemctl restart php-fpm || service php-fpm restart

Задание параметра в коде приложения

Способ может быть полезен, когда разные страницы портала должны иметь разное время жизни сессии. Для этого можно воспользоваться PHP-функциями ini_set и session_set_cookie_params, например:

ini_set(‘session.gc_maxlifetime’, 86400);
ini_set(‘session.cookie_lifetime’, 0);
session_set_cookie_params(0);

Функции обязательно вызывать до открытия сесии (session_start).

Установка сессии в приложении

Некоторые приложения могут переопределять настройки. В таком случае, задать время жизни сессии необходимо в параметрах программы. У каждого приложения свои настройки, в которых необходимо самостоятельно разобраться. Приведем для примера настройку сессии в CMS Битрикс.

Заходим в Группы пользователей — выбираем группу — Безопасность. Находим параметр «Время жизни сессии (минут)» и ставим время, например 1440 (24 часа в минутах).

Как автоматически продлевать сессии

Если сессия выдается на определенный период и заканчивается в определенное время, это может привести к прерыванию активного сеанса пользователя. Гораздо удобнее, если время действия сессии будет автоматически продлеваться, если посетитель обновляет страницу. Для этого существует параметр cookie_lifetime, который во всех примерах выше мы задавали в значении 0.

Если мы зададим значение cookie_lifetime 86400, то через 24 часа сессия прервется. Это не всегда удобно.

Если есть необходимость в контроле и прерывании сессии, можно воспользоваться php-функцией session_destroy().

Путь хранения файлов сессий

Место хранения файлов сессий задается параметром session.save_path также, так время жизни. По умолчанию, может использоваться путь /var/lib/php/sessions.

Это важный параметр — если у веб-сервера будут отсутствовать права на запись в данный каталог, это приведет к невозможности хранить сессии, что вызовет неожиданные результаты работы приложений.

Источник

Cookie setting in php ini

Предоставляя INI-настройки, связанные с сессиями, вы можете улучшить безопасность сессий. Некоторые важные настройки безопасности не имеют рекомендованных значений. Вы сами ответственны за выбор необходимых значений.

• session.cookie_lifetime=0 0 имеет особое значение. Он сообщает браузеру не сохранять cookie в постоянное хранилище. Следовательно, когда браузер закрывается, сессионные cookie сразу же удаляются. Если задать значение отличное от 0, это может позволить другим пользователям использовать эти cookie. В большинстве случаев лучше всего использовать » 0 «. Если требуется функциональность автологина, реализовывайте его самостоятельно и никогда не используйте для этого долгоживущие сессии. Более подробно изложено выше в соответствующих разделах.
• session.use_cookies=On session.use_only_cookies=On Несмотря на то, что HTTP-cookie имеют некоторые проблемы, всё же они наиболее предпочтительны для хранения идентификатора сессии. Когда это возможно, для управления идентификаторами сессий необходимо использовать «cookie». Большинство приложений должны использовать cookie для идентификатора сессии. Если session.use_only_cookies=Off, модуль сессии будет использовать идентификатор, установленный через GET или POST, если «cookie» не была выставлена заранее.
• session.use_strict_mode=On Крайне рекомендуется включать session.use_strict_mode. По умолчанию не включено. Это не позволит сессионному модулю использовать неинициализированные идентификаторы сессий. Другими словами, сессионный модуль будет принимать только корректные идентификаторы, сгенерированные им же и будет игнорировать идентификаторы созданные на стороне пользователя. Из-за особенностей спецификации cookie, атакующий может сделать cookie с идентификатором сессии неудаляемой с помощью локальной базы cookie или JavaScript-инъекцией. session.use_strict_mode может не дать атакующему использовать этот идентификатор.

Замечание: Атакующие могут инициализировать идентификатор сессии на своём устройстве и выставить его жертве. Они должны будут поддерживать сессию в активном состоянии для злоупотреблений. Атакующим понадобится совершить дополнительные действия для проведения атаки по этому сценарию. Поэтому session.use_strict_mode служит как предотвращение этому.

Замечание: Защитный ключ CSRF должен периодически обновляться, как и идентификатор сессии.

Замечание: Некоторые обработчики сохранения сессий не используют механизм устаревания сессий на основе вероятностей. Например memcached, memcache. Читайте соответствующую документацию для более полной информации.

Замечание: Идентификатор сессии может утечь через закладку в браузере, URL посланный по почте, сохранённый исходник HTML.

Источник

Session.cookie_domain in php.ini

I have been reading as much as possible about the php.ini file and i have found nothing about whether or not its bad/dangerous to not set the session.cookie_domain in the php.ini. We are in a production environment and this is not set. Are there security issues with not setting this. Cookies appear to be working well, no real issues. The php.ini file looks like this:

1 Answer 1

Original answer (Edited to remove incorrect parts)

I disagree with the accepted answer. I think session.cookie_domain is not a configuration directive that allow you to restrict subdomains but to allow subdomains. If you read PHP manual, it says if the value of the directive is not defined (none, default value) then the host name of the machine that generated the cookie is used as cookie domain.

 session.cookie_domain specifies the domain to set in the session cookie. Default is none at all meaning the host name of the server which generated the cookie according to cookies specification. See also session_get_cookie_params() and session_set_cookie_params(). 

Also, by default, PHP is configured so that sessions are unique to a domain. If you don’t specify one but if the domain of the server is example.org, your cookies will be valid only for example.org domain, and invalid for any sub-domain like app.example.org or any other domain like corp.com .

The goal of session.cookie_domain is to actually allow the usage of sub-domains, so if you set session.cookie_domain = «example.org» it will act as a wildcard and accept any sub-domains.

So setting a wildcard session.cookie_domain = «example.org» is way more open to attacks than not setting it.

Updated answer

By reading Set-Cookie — MDN and Using HTTP cookies — HTTP — MDN, it seems that PHP behavior is deprecated.

Domain=

Defines the host to which the cookie will be sent.

If omitted, this attribute defaults to the host of the current document URL, not including subdomains.

Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored.

Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included.

The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.

For example, if you set Domain=mozilla.org, cookies are available on subdomains like developer.mozilla.org.

It seems that current behavior is to ignore leading dot and to implicitly allow all subdomains when you specify a domain. So in fact, the final answer is that using Domain is less secure that not using it. So the reality is exactly the opposite of the accepted answer.

Источник