svn: /phpdoc/de/trunk/reference/session/ security.xml

Deleted: phpdoc/de/trunk/reference/session/security.xml
===================================================================
--- phpdoc/de/trunk/reference/session/security.xml	2018-04-21 21:23:55 UTC (rev 344797)
+++ phpdoc/de/trunk/reference/session/security.xml	2018-04-21 21:24:20 UTC (rev 344798)
@@ -1,312 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- $Revision$ -->
-<!-- EN-Revision: 297028 Maintainer: samesch Status: wip -->
-
-<chapter xml:id="session.security" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
- <title>Sessions und Sicherheit</title>
- <para>
-  Externe Links: <link xlink:href="&url.session-fixation;">Session
-  fixation</link>
- </para>
- <para>
-  Das HTTP-Sessionmanagement ist das Kernstück der Websicherheit. Alle
-  vorbeugenden Maßnahmen sollten berücksichtigt werden, um die Sicherheit der
-  Sessions zu gewährleisten. Entwickler sollten die maßgeblichen
-  Konfigurationsparameter entsprechend aktivieren/nutzen.
- </para>
-
- <itemizedlist>
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.cookie-lifetime">session.cookie_lifetime</link>=0.
-    0 hat eine besondere Bedeutung. Mit dieser Einstellung wird Browsern
-    mitgeteilt, Cookies nicht dauerhaft zu speichern.
-    Daraus folgt das der Session-ID-Cookie für die Session direkt bei Beenden des Browsers gelöscht wird.
-    Ein anderer Wert als 0 erlaubt es anderen Usern die Session-ID zu verwenden.
-    Deswegen sollten die meisten Seiten den Wert "0" für diese Einstellung verwenden.
-    Sollte ein Auto-Login Feature benötigt werden, implementiere dein eigenes sicheres Feature.
-    Benutze keine Session-IDs für so eine Funktion.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link linkend="ini.session.use-cookies">session.use_cookies</link>=On und
-    <link
-    linkend="ini.session.use-only-cookies">session.use_only_cookies</link>=On.
-    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.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.use-strict-mode">session.use_strict_mode</link>=On.
-    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. Session ID injection could be done by cookie injection via
-    JavaScript permanently or temporarily. When transparent session is
-    enabled, session ID could be injected via query string or form
-    parameter. There is no reason to accept user supplied session ID,
-    most applications must not accept user supplied uninitialized
-    session ID.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.cookie-httponly">session.cookie_httponly</link>=On.
-    Disallow access to session cookie by JavaScript. This setting
-    prevents cookies stolen by JavaScript injection.  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.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link linkend="ini.session.cookie-secure">session.cookie_secure</link>=On.
-    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. Use of HSTS should be considered for HTTPS only web site.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.gc-maxlifetime">session.gc_maxlifetime</link>=[choose smallest possible].
-    GC is performed by probability. This setting does not guarantee old
-    session deletion. Some session save handler modules do not use
-    this setting. Refer to session save handler documentation for
-    details. 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.
-    Do not use long life session ID for it.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.use-trans-sid">session.use_trans_sid</link>=Off.
-    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.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.referer-check">session.referer_check</link>=[your originating URL]
-    When <link
-    linkend="ini.session.use-trans-sid">session.use_trans_sid</link>
-    is enabled, use of this setting is recommended if it is
-    possible. 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.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.cache-limiter">session.cache_limiter</link>=nocache.
-    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.
-   </simpara>
-  </listitem>
-
-  <listitem>
-   <simpara>
-    <link
-    linkend="ini.session.hash-function">session.hash_function</link>="sha256".
-    Stronger hash function will generates stronger session
-    ID. Although hash collision is unlikely even with MD5 hash, developers
-    should use SHA-2 or later hash functions for the task. Developers may
-    use stronger hashes like sha384 and sha512.
-   </simpara>
-  </listitem>
- </itemizedlist>
-
- <para>
-  Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie
-  in einer Session speichern, nur vom Benutzer gesehen werden können, der die
-  Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die
-  Vertraulichkeit der Session ihrer Wichtigkeit entsprechend angemessen aktiv
-  zu schützen.
- </para>
-
- <para>
-  Schätzen Sie die Wichtigkeit der Daten ab, die in Ihren Sessions
-  transportiert werden und treffen Sie zusätzliche Schutzmaßnahmen - in der
-  Regel bezahlen Sie dafür mit einer geringeren Benutzerfreundlichkeit. Wenn
-  Sie z.B. Benutzer vor einfachen Social Engineering Tactics (Anm. des
-  Übersetzers: Techniken der Ausnutzung menschlicher Schwächen) schützen
-  wollen, müssen Sie <literal>session.use_only_cookies</literal> aktivieren.
-  Cookies müssen dann benutzerseitig auf jeden Fall aktiviert sein, weil
-  Sessions sonst nicht funktionieren.
- </para>
-
- <para>
-  Es gibt mehrere Wege, über die eine Session-ID an Dritte gelangen kann. Eine
-  entführte Session-ID ermöglicht diesen, auf alle Daten zuzugreifen, die mit
-  dieser Session-ID verbunden sind. Zum einen sind das URLs, die Session-IDs
-  enthalten. Wenn Sie auf eine externe Site verweisen, könnte die URL
-  inklusive Session-ID in den Referrer-Logs der externen Site gespeichert
-  werden. Zum anderen kann ein aktiverer Angreifer Ihren Netzwerkverkehr
-  abhören. Falls Ihr Netzwerkverkehr nicht verschlüsselt ist, werden
-  Session-IDs im Klartext über das Netzwerk übertragen. Hier ist die Lösung,
-  auf Ihrem Server SSL zu implementieren und die Verwendung für Ihre Benutzer
-  obligatorisch zu machen. Hierfür sollte HSTS verwendet werden.
- </para>
-
- <para>
-  Since PHP 5.5.2, <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-  is available. When it is enabled and save handler module supports
-  it, uninitialized session ID is rejected and new session ID is
-  created. This protects attack that force users to use known session
-  ID. Attacker may paste links or send mail that contains session
-  ID. e.g. http://example.com/page.php?PHPSESSID=123456789 If <link
-  linkend="ini.session.use-trans-sid">session.use_trans_sid</link> is
-  enabled, victim will start session using attacker provided session
-  ID.  <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-  mitigates the risk.
- </para>
-
- <para>
-  Even though <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-  mitigates risk of adoptive session management, attacker can force
-  users to use initialized session ID which is created by
-  attacker. All attacker has to do is initialize session ID prior to
-  attack and keep it alive.
- </para>
-
- <para>
-  Session ID cookie could be set with domain, path, httponly, secure
-  attributes. There is precedence defined by browsers. By using the
-  precedence, attacker can set session ID that could be used
-  permanently. Use of <link
-  linkend="ini.session.use-only-cookies">session.use_only_cookies</link>
-  will not solve this issue. <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-  mitigates this risk. With <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>=On,
-  uninitialized session ID will not be accepted. Session module
-  creates new session ID always when session ID is not initialized by
-  session module. This could result in DoS to victim, but DoS is
-  better than compromised account.
- </para>
-
- <para>
-  <link
-  linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-  is good mitigation, but it is not enough mitigation for
-  authenticated session. Developer must use
-  <function>session_regenerate_id</function> for authentication.
-  <function>session_regenerate_id</function> must be called prior to
-  set authentication information to
-  $_SESSION. <function>session_regenerate_id</function> makes sure new
-  session contains authenticated information stored only in new
-  session. i.e. Errors during authentication process may save
-  authenticated flag in old session.
- </para>
-
- <para>
-  Calling <function>session_regenerate_id</function> function could
-  result in personal DoS like use_strict_mode=On. However, DoS is
-  better than compromised account. Session ID should be regenerated
-  when user is authenticated at least. Session ID regeneration reduces
-  risk of stolen session ID, thus is should be called periodically.
-  Developer should not rely on session ID expiration. Attackers may
-  access victim's session ID periodically to prevent expiration.
-  Developers must implement their own expiration feature for old sessions.
- </para>
-
- <para>
-  Note that <function>session_regenerate_id</function> does not delete
-  old session by default. Old authenticated session may be available
-  for use. If developer would like to prevent old authenticated session to
-  be used by anyone, developer must destroy session by setting
-  <parameter>delete_old_session</parameter> to &true;. However,
-  immediate old session deletion has unwanted side effect. Session
-  could be vanished when there are concurrent connections to web
-  application and/or network is unstable. Instead of deleting old
-  session immediately, you may set short term expiration time in
-  $_SESSION by yourselves. If user accesses to obsolete
-  session(expired session), deny access to it.
- </para>
-
- <para>
-  <link
-  linkend="ini.session.use-only-cookies">session.use_only_cookies</link>
-  and proper use of <function>session_regenerate_id</function> could
-  cause personal DoS. When this is the case, you may ask users to
-  remove cookies and warn users that there could be possible security
-  issues. Attackers may set malicious cookies via vulnerable web
-  application (i.e. JavaScript injection), vulnerable/malicious
-  browser plugins, etc.
- </para>
-
- <para>
-  Developers must not use long life session ID for auto login as it
-  increases risk of stolen session. Auto login should be implemented
-  by developer. Use secure one time hash key as auto login key using
-  cookie. Use secure hash stronger than SHA-2. e.g. SHA-256 or greater
-  with random data from /dev/urandom or like. If user is not
-  authenticated, check the one time auto login key is valid or not. If
-  key is valid, authenticate user and set new secure one time hash
-  key. Auto login key is long lived authentication key, this key should
-  be protected as much as possible. Use path/httponly/secure
-  attributes of cookie to protect. Developer must implement feature that
-  disables auto login and removes unneeded auto login key cookie for
-  users.
- </para>
-</chapter>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-omittag:t
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-indent-tabs-mode:nil
-sgml-parent-document:nil
-sgml-default-dtd-file:"~/.phpdoc/manual.ced"
-sgml-exposed-tags:nil
-sgml-local-catalogs:nil
-sgml-local-ecat-files:nil
-End:
-vim600: syn=xml fen fdm=syntax fdl=2 si
-vim: et tw=78 syn=sgml
-vi: ts=1 sw=1
--->
-