rfc:secure-session-options-by-default

This is an old revision of the document!


PHP RFC: Secure Session Module Options/Internal by Default

Introduction

HTTP session management is core of Web security. Current default of session module options are weaker than it could be. Secure values by default would be better.

Proposal

Secure setting should be the default and user should selectively use weaker setting.

use_strict_mode=on disallow user supplied session ID and improve session ID security. Most applications work with this option.

cookie_httponly=on disallow use of session ID cookie from JavaScript. It reduces risk of stolen session ID via JavaScript injections. Most applications work with this option.

hash_function=“sha256” SHA-256 has larger bits than SHA-1/MD5. (256 bits vs 160/128 bits) More difficult to guess. i.e. Birthday attack. With stronger hash,collision is less likely.

NIST suggests not to use SHA-1 for “applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010.” Files save handler detects session ID collision (PHP 5.5 and later). Therefore it is out of NIST requirement scope for small sites, but collision detection is up to save handlers.

“sha256” is Hash extension function. Hash extension is built by default, but “sha256” could be unavailable. Session module raises E_ERROR if Hash extension is unavailable.

entropy_length=64 entropy_lengh=32 is too short for SHA-256. Default to 64.

Backward Incompatible Changes

use_strict_mode=on: Do not accept user provided session ID. User may send obsolete and/or attacker provided session ID. This prevents these invalid session ID. Applications that assume certain session ID for data sharing/etc would not work with strict mode. Users may turn off at their own risks.

cookie_httponly=on: JavaScript cannot access session ID cookie. Even when web app has JavaScript injection vulnerability, session ID cannot be stolen. JavaScript injection vulnerability is the most common issue of web apps. Applications that uses session ID as CSRF protection key would be affected. However, use of session ID as CSRF key is bad practice. Session ID could be stolen by BREACH attack even with HTTPS, for example.

hash_function=“sha256”: Longer session ID string. NIST suggests to use SHA-2 or stronger hash for security related features. If session database has limited storage, session ID cannot be stored. Users should use weaker hash or modify database schema in this case. Hash extension could be unavailable. If “sha256” is not usable (not compiled or compiled as DL module), E_ERROR is raised and script stops.

Proposed PHP Version(s)

PHP 5.x+

Impact to Existing Extensions

Session module

php.ini Defaults

  • hardcoded default values
  • php.ini-development values
  • php.ini-production values

use_strict_mode=on, cookie_httponly=on, hash_function=sha256, entropy_length=64 for all

Open Issues

Future Scope

  • When use of HTTPS becomes dominant, session.cookie_secure=on should be used.
  • Build ext/hash always. If SHA-256(Hash extension which is built by default) is not available, session raises E_ERROR for it.
  • Detect collision via PS_VALIDATE_FUNC() When session ID is generated, collision could be checked by PS_VALIDATE_FUNC() if it is available. Check collision in session module instead of save handler module. (Easier use_strict_mode adoption)

Proposed Voting Choices

Yes/No

VOTE

VOTE: 2014/XX/XX - 2014/XX/XX

Secure Session Module Options by Default
Real name Yes No
Final result: 0 0
This poll has been closed.

Thank you for voting!

Implementation

After the project is implemented, this section should contain

  1. the version(s) it was merged to
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature

References

Rejected Features

Keep this updated with features that were discussed on the mail lists.

rfc/secure-session-options-by-default.1399881531.txt.gz · Last modified: 2017/09/22 13:28 (external edit)