PHP RFC: Secure Session Module Options/Internal by Default

• Version: 0.11
• Created: 2014-02-01
• Modified: 2014-05-12
• Author: Yasuo Ohgaki, yohgaki@ohgaki.net
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/secure-session-options-by-default

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.

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.

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.

PHP 5.x+

Session module

• 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

• 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)

Yes/No

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

Thank you for voting!

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

1. https://wiki.php.net/rfc/session-lock-ini
2. Collision probability - http://preshing.com/20110504/hash-collision-probabilities/
3. NIST advises not to use SHA-1 - http://csrc.nist.gov/groups/ST/hash/policy_2006.html

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