mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 16:38:54 +00:00
Change section order
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@339999 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
parent
b3b25b7308
commit
529deaf927
1 changed files with 261 additions and 256 deletions
|
@ -12,261 +12,6 @@
|
|||
enable/use applicable security measures.
|
||||
</para>
|
||||
|
||||
<sect1 xml:id="session.security.ini">
|
||||
<title>Securing Session INI Settings</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-lifetime">session.cookie_lifetime</link>=0
|
||||
</para>
|
||||
<para>
|
||||
0 have special meaning. It tells browsers not to store cookie to
|
||||
permanent storage. Therefore, when browser is terminated, session
|
||||
ID cookie is deleted immediately. If developer set other than 0, it may
|
||||
allow other users to use the session ID. Most applications should
|
||||
use "0" for this.
|
||||
</para>
|
||||
<para>
|
||||
If auto login feature is required, implement your own secure auto login
|
||||
feature. Do not use long life session ID for it.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-cookies">session.use_cookies</link>=On
|
||||
</para>
|
||||
<para>
|
||||
<link linkend="ini.session.use-only-cookies">session.use_only_cookies</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Although HTTP cookie has some problems, cookie is preferred way to
|
||||
manage session ID. Use only cookies for session ID management when
|
||||
it is possible. Most applications should use cookie for session
|
||||
ID.
|
||||
</para>
|
||||
<para>
|
||||
If <literal>session.use_only_cookies</literal>=Off,
|
||||
session module will use session ID values set by GET/POST/URL is used when
|
||||
session ID cookie is not initialized already.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-strict-mode">session.use_strict_mode</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Although, enabling <literal>session.use_strict_mode</literal> is
|
||||
mandatory. It is not enabled by default.
|
||||
</para>
|
||||
<para>
|
||||
This prevents session module to use uninitialized session ID. In
|
||||
other word, session module only accepts valid session ID generated
|
||||
by session module. It rejects session ID supplied by
|
||||
users.
|
||||
</para>
|
||||
<para>
|
||||
Because of cookie spec, attackers are able to set undeletable session ID
|
||||
cookies via locally setting cookie database or JavaScript injections.
|
||||
<literal>session.use_strict_mode</literal> can prevent attacker
|
||||
initialized session ID being used.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Attackers may initialize session ID by their device and may set the
|
||||
session ID to victim. They must keep the session ID active to abuse.
|
||||
Attackers require additional steps to perform attack with this attack
|
||||
scenario. Therefore, <literal>session.use_strict_mode</literal> works
|
||||
as the mitigation.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-httponly">session.cookie_httponly</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Disallow access to session cookie by JavaScript. This setting
|
||||
prevents cookies stolen by JavaScript injection.
|
||||
</para>
|
||||
<para>
|
||||
It is possible to use session ID as CSRF protection key, but this is not
|
||||
recommended. For example, HTML source may be saved and sent to
|
||||
other users. Developer should not write session ID in web pages for
|
||||
better security. Almost all applications must use httponly attribute for
|
||||
session ID cookie.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
CSRF protection token should be renewed periodically just like
|
||||
session ID
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-secure">session.cookie_secure</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Allows access to session ID cookie only when protocol is HTTPS. If
|
||||
your web site is HTTPS only web site, you must enable this
|
||||
setting.
|
||||
</para>
|
||||
<para>
|
||||
HSTS should be considered for HTTPS only web site.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.gc-maxlifetime">session.gc_maxlifetime</link>=[choose smallest possible]
|
||||
</para>
|
||||
<para>
|
||||
<literal>session.gc_maxlifetime</literal>
|
||||
is setting for deleting obsolete session ID. Reliance on this setting
|
||||
is NOT recommend. You should manage session life time by time-stamp
|
||||
by yourself.
|
||||
</para>
|
||||
<para>
|
||||
Session GC(garbage collection) is better to be performed by <function>session_gc</function>.
|
||||
<function>session_gc</function> function is better to be executed by task
|
||||
managers. e.g. cron on UNIX like systems.
|
||||
</para>
|
||||
<para>
|
||||
GC is performed by probability by default. This setting does not
|
||||
guarantee old session deletion. Although developer cannot rely
|
||||
on this setting, setting this to smallest possible value is
|
||||
recommended. Adjust <link
|
||||
linkend="ini.session.gc-probability">session.gc_probability</link>
|
||||
and <link
|
||||
linkend="ini.session.gc-divisor">session.gc_divisor</link> so
|
||||
that obsolete sessions are deleted by appropriate frequency. If
|
||||
auto login feature is required, implement your own secure auto
|
||||
login feature. Never use long life session ID for it.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Some session save handler modules do not use this setting for
|
||||
probability based expiration . e.g. memcached, memcache.
|
||||
Refer to session save handler documentation for details.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-trans-sid">session.use_trans_sid</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
Use of transparent session ID management is not prohibited. You
|
||||
may use it when it is needed. However, disabling transparent
|
||||
session ID management would improve general session ID security by
|
||||
removing possibility of session ID injection and session ID leak.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Session ID may leak from bookmarked URL, e-mailed URL, saved HTML
|
||||
source.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.trans-sid-tags">session.trans_sid_tags</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) You should not rewrite unneeded HTML tags. Default
|
||||
would be good enough for most usage. Older PHP uses
|
||||
<link linkend="ini.url-rewriter.tags">url_rewriter.tags</link> for this.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.trans-sid-hosts">session.trans_sid_hosts</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) This INI defines whitelist hosts that allows trans sid
|
||||
rewrite. Never add untrusted host. Session module allow only $_SERVER['HTTP_HOST']
|
||||
when this setting is empty.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.referer-check">session.referer_check</link>=[your originating URL]
|
||||
</para>
|
||||
<para>
|
||||
When <link
|
||||
linkend="ini.session.use-trans-sid">session.use_trans_sid</link>
|
||||
is enabled, use of this setting is recommended.
|
||||
It reduces risk of session ID injection. If your site is
|
||||
http://example.com/, set http://example.com/ to it. Note that when
|
||||
HTTPS is used, browser will not send referrer header. Browser may
|
||||
not send referrer header by configuration. Therefore, this setting
|
||||
is not reliable security measure.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cache-limiter">session.cache_limiter</link>=nocache
|
||||
</para>
|
||||
<para>
|
||||
Make sure HTTP contents are not cached for authenticated
|
||||
session. Allow caching only when contents is not private.
|
||||
Otherwise, contents may be exposed. "private" may be used
|
||||
if HTTP content does not include security sensitive data. Note
|
||||
that "private" may leave private data cached by shared
|
||||
clients. "public" may be used only when HTTP content does not
|
||||
contain any private data at all.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.sid-length">session.sid_length</link>="48"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) Longer session ID results in stronger session
|
||||
ID. Developer should consider session ID length 32 chars or more. At
|
||||
least 26 chars is required when
|
||||
<link linkend="ini.session.sid-bits-per-character">session.sid_bits_per_character</link>="5".
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.sid-bits-per-character">session.sid_bits_per_character</link>="6"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) The more bits in a session ID char, session module
|
||||
generates stronger session ID for the same session ID length.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.hash-function">session.hash_function</link>="sha256"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 <) Stronger hash function will generates stronger session
|
||||
ID. Although hash collision is unlikely even with MD5 hash, developers
|
||||
should use SHA-2 or stronger hash functions for the task. Developers may
|
||||
use stronger hashes like sha384 and sha512. Make sure you feed long
|
||||
enough <link linkend="ini.session.entropy-length">entropy</link> for
|
||||
the hash function used.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="features.session.security.management">
|
||||
<title>Session Management Basics</title>
|
||||
|
||||
|
@ -716,8 +461,268 @@
|
|||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</sect1>
|
||||
<sect1 xml:id="session.security.ini">
|
||||
<title>Securing Session INI Settings</title>
|
||||
|
||||
<para>
|
||||
By securing session related INI settings, you can improve session security.
|
||||
Some of important INI settings does not have recommended settings. You
|
||||
are responsible to hardening session settings.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-lifetime">session.cookie_lifetime</link>=0
|
||||
</para>
|
||||
<para>
|
||||
0 have special meaning. It tells browsers not to store cookie to
|
||||
permanent storage. Therefore, when browser is terminated, session
|
||||
ID cookie is deleted immediately. If developer set other than 0, it may
|
||||
allow other users to use the session ID. Most applications should
|
||||
use "0" for this.
|
||||
</para>
|
||||
<para>
|
||||
If auto login feature is required, implement your own secure auto login
|
||||
feature. Do not use long life session ID for it.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-cookies">session.use_cookies</link>=On
|
||||
</para>
|
||||
<para>
|
||||
<link linkend="ini.session.use-only-cookies">session.use_only_cookies</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Although HTTP cookie has some problems, cookie is preferred way to
|
||||
manage session ID. Use only cookies for session ID management when
|
||||
it is possible. Most applications should use cookie for session
|
||||
ID.
|
||||
</para>
|
||||
<para>
|
||||
If <literal>session.use_only_cookies</literal>=Off,
|
||||
session module will use session ID values set by GET/POST/URL is used when
|
||||
session ID cookie is not initialized already.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-strict-mode">session.use_strict_mode</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Although, enabling <literal>session.use_strict_mode</literal> is
|
||||
mandatory. It is not enabled by default.
|
||||
</para>
|
||||
<para>
|
||||
This prevents session module to use uninitialized session ID. In
|
||||
other word, session module only accepts valid session ID generated
|
||||
by session module. It rejects session ID supplied by
|
||||
users.
|
||||
</para>
|
||||
<para>
|
||||
Because of cookie spec, attackers are able to set undeletable session ID
|
||||
cookies via locally setting cookie database or JavaScript injections.
|
||||
<literal>session.use_strict_mode</literal> can prevent attacker
|
||||
initialized session ID being used.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Attackers may initialize session ID by their device and may set the
|
||||
session ID to victim. They must keep the session ID active to abuse.
|
||||
Attackers require additional steps to perform attack with this attack
|
||||
scenario. Therefore, <literal>session.use_strict_mode</literal> works
|
||||
as the mitigation.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-httponly">session.cookie_httponly</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Disallow access to session cookie by JavaScript. This setting
|
||||
prevents cookies stolen by JavaScript injection.
|
||||
</para>
|
||||
<para>
|
||||
It is possible to use session ID as CSRF protection key, but this is not
|
||||
recommended. For example, HTML source may be saved and sent to
|
||||
other users. Developer should not write session ID in web pages for
|
||||
better security. Almost all applications must use httponly attribute for
|
||||
session ID cookie.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
CSRF protection token should be renewed periodically just like
|
||||
session ID
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cookie-secure">session.cookie_secure</link>=On
|
||||
</para>
|
||||
<para>
|
||||
Allows access to session ID cookie only when protocol is HTTPS. If
|
||||
your web site is HTTPS only web site, you must enable this
|
||||
setting.
|
||||
</para>
|
||||
<para>
|
||||
HSTS should be considered for HTTPS only web site.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.gc-maxlifetime">session.gc_maxlifetime</link>=[choose smallest possible]
|
||||
</para>
|
||||
<para>
|
||||
<literal>session.gc_maxlifetime</literal>
|
||||
is setting for deleting obsolete session ID. Reliance on this setting
|
||||
is NOT recommend. You should manage session life time by time-stamp
|
||||
by yourself.
|
||||
</para>
|
||||
<para>
|
||||
Session GC(garbage collection) is better to be performed by <function>session_gc</function>.
|
||||
<function>session_gc</function> function is better to be executed by task
|
||||
managers. e.g. cron on UNIX like systems.
|
||||
</para>
|
||||
<para>
|
||||
GC is performed by probability by default. This setting does not
|
||||
guarantee old session deletion. Although developer cannot rely
|
||||
on this setting, setting this to smallest possible value is
|
||||
recommended. Adjust <link
|
||||
linkend="ini.session.gc-probability">session.gc_probability</link>
|
||||
and <link
|
||||
linkend="ini.session.gc-divisor">session.gc_divisor</link> so
|
||||
that obsolete sessions are deleted by appropriate frequency. If
|
||||
auto login feature is required, implement your own secure auto
|
||||
login feature. Never use long life session ID for it.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Some session save handler modules do not use this setting for
|
||||
probability based expiration . e.g. memcached, memcache.
|
||||
Refer to session save handler documentation for details.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.use-trans-sid">session.use_trans_sid</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
Use of transparent session ID management is not prohibited. You
|
||||
may use it when it is needed. However, disabling transparent
|
||||
session ID management would improve general session ID security by
|
||||
removing possibility of session ID injection and session ID leak.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Session ID may leak from bookmarked URL, e-mailed URL, saved HTML
|
||||
source.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.trans-sid-tags">session.trans_sid_tags</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) You should not rewrite unneeded HTML tags. Default
|
||||
would be good enough for most usage. Older PHP uses
|
||||
<link linkend="ini.url-rewriter.tags">url_rewriter.tags</link> for this.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.trans-sid-hosts">session.trans_sid_hosts</link>=Off
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) This INI defines whitelist hosts that allows trans sid
|
||||
rewrite. Never add untrusted host. Session module allow only $_SERVER['HTTP_HOST']
|
||||
when this setting is empty.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.referer-check">session.referer_check</link>=[your originating URL]
|
||||
</para>
|
||||
<para>
|
||||
When <link
|
||||
linkend="ini.session.use-trans-sid">session.use_trans_sid</link>
|
||||
is enabled, use of this setting is recommended.
|
||||
It reduces risk of session ID injection. If your site is
|
||||
http://example.com/, set http://example.com/ to it. Note that when
|
||||
HTTPS is used, browser will not send referrer header. Browser may
|
||||
not send referrer header by configuration. Therefore, this setting
|
||||
is not reliable security measure.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.cache-limiter">session.cache_limiter</link>=nocache
|
||||
</para>
|
||||
<para>
|
||||
Make sure HTTP contents are not cached for authenticated
|
||||
session. Allow caching only when contents is not private.
|
||||
Otherwise, contents may be exposed. "private" may be used
|
||||
if HTTP content does not include security sensitive data. Note
|
||||
that "private" may leave private data cached by shared
|
||||
clients. "public" may be used only when HTTP content does not
|
||||
contain any private data at all.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.sid-length">session.sid_length</link>="48"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) Longer session ID results in stronger session
|
||||
ID. Developer should consider session ID length 32 chars or more. At
|
||||
least 26 chars is required when
|
||||
<link linkend="ini.session.sid-bits-per-character">session.sid_bits_per_character</link>="5".
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.sid-bits-per-character">session.sid_bits_per_character</link>="6"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 >=) The more bits in a session ID char, session module
|
||||
generates stronger session ID for the same session ID length.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ini.session.hash-function">session.hash_function</link>="sha256"
|
||||
</para>
|
||||
<para>
|
||||
(PHP 7.1.0 <) Stronger hash function will generates stronger session
|
||||
ID. Although hash collision is unlikely even with MD5 hash, developers
|
||||
should use SHA-2 or stronger hash functions for the task. Developers may
|
||||
use stronger hashes like sha384 and sha512. Make sure you feed long
|
||||
enough <link linkend="ini.session.entropy-length">entropy</link> for
|
||||
the hash function used.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
|
Loading…
Reference in a new issue