The default behavior of sessions can be modified using the static methods in Zend_Session_Core. All management
and manipulation of global session management occurs using Zend_Session_Core, including configuration of the
usual options provided by ext/session
, using Zend_Session::setOptions()
.
When the first session namespace is requested, Zend_Session_Core will autostart itself, unless already
started explicitly by using
Zend_Session_Core::start()
. The underlying PHP session will use defaults from Zend_Session_Core, unless modified first by
Zend_Session::setOptions()
.
To pass the options just pass the basename (the non session.
part) as part of an array to
setOptions. Without setting any options, Zend_Session will utilize the recommended options first, then the
default php.ini settings. Community feedback about best practices for these options should be sent to
fw-auth@lists.zend.com
.
To "automatically" configure this component using an ".ini" file with Zend_Config_Ini:
Example 21.11. Using Zend_Config to Configure Zend_Session
<?php $config = new Zend_Config_Ini('myapp.ini', 'sandbox'); require_once 'Zend/Session.php'; Zend_Session_Core::setOptions($config->asArray()); ?>
The corresponding "myapp.ini" file:
Example 21.12. myapp.ini
; Defaults for our live servers [live] ; bug_compat_42 ; bug_compat_warn ; cache_expire ; cache_limiter ; cookie_domain ; cookie_lifetime ; cookie_path ; cookie_secure ; entropy_file ; entropy_length ; gc_divisor ; gc_maxlifetime ; gc_probability ; hash_bits_per_character ; hash_function ; name should be unique for each PHP application sharing the same domain name name = UNIQUE_NAME ; referer_check ; save_handler ; save_path ; serialize_handler ; use_cookies ; use_only_cookies ; use_trans_sid ; remember_me_seconds = <integer seconds> ; strict = on|off ; Our sandbox server uses the same settings as our live server, ; except as overridden below: [sandbox : live] ; Don't forget to create this directory and make it rwx (readable and modifiable) by PHP. save_path = /home/myaccount/zend_sessions/myapp use_only_cookies = on ; When persisting session id cookies, request a TTL of 10 days remember_me_seconds = 864000
Most options shown above need no explanation beyond that found in the standard PHP documentation.
boolean strict
- disables automatic starting of Zend_Session_Core
when
using new Zend_Session()
.
integer remember_me_seconds
- how long should session id cookie persist, after user
agent has ended (i.e. browser window closed)
string save_path
- The correct value is system dependent, and should be provided by
the developer using an absolute path to a directory readable
and writable by the PHP process.
![]() |
Security Risk |
---|---|
If the path is readable by other applications, then session hijacking might be possible. If the path is writable by other applications, then session poisoning might be possible. If this path is shared with other users or other PHP applications, various security issues might occur, including theft of session content, hijacking of sessions, and collision of garbage collection (e.g. another user's application might cause PHP to delete your application's session files).
For example, an attacker can visit the victim's website to obtain a session cookie. Then
edit the cookie path to his own domain on the same server, before visiting his own website
to execute |
string name
- The correct value is system dependent, and should be provided by
the developer using a short value unique to the ZF
application.
![]() |
Security Risk |
---|---|
If the |
boolean use_only_cookies
- In order to avoid introducing additional security risks,
do not alter the default value of this option.
![]() |
Security Risk |
---|---|
If this setting is not enabled, an attacker can easily fix victim's session ids, using
links on the attacker's website, such as
|
Introduction: Best practice in relation to using sessions with ZF calls for using a browser cookie (i.e.
a normal cookie stored in your web browser), instead of embedding a unique session identifier in URLs as
a means to track individual users. By default this component uses only cookies to maintain session
identifiers. The cookie's value is the unique identifier of your browser's session. PHP's ext/session
uses this identifier to maintain a unique one-to-one relationship between website visitors, and
persistent session data storage unique to each visitor. Zend_Session* wraps this storage mechanism
($_SESSION
) with an object-oriented interface. Unfortunately, if an attacker gains access
to the value of the cookie (the session id), an attacker might be able to hijack a visitor's session.
This problem is not unique to PHP, or the Zend Framework. The regenerateId()
method allows
an application to change the session id (stored in the visitor's cookie) to a new, random, unpredictable
value. Note: Although not the same, to make this section easier to read, we use the terms "user agent"
and "web browser" interchangeably.
Why?: If an attacker obtains a valid session identifier, an attacker might be able to impersonate a
valid user (the victim), and then obtain access to confidential information or otherwise manipulate the
victim's data managed by your application. Changing session ids helps protect against session hijacking.
If the session id is changed, and an attacker does not know the new value, the attacker can not use the
new session id in their attempts to hijack the visitor's session. Even if an attacker gains access to an
old session id, regenerateId()
also moves the session data from the old session id "handle"
to the new one, so no data remains accessible via the old session id.
When to use regenerateId(): Adding Zend_Session_Core::regenerateId()
to your Zend Framework
bootstrap yields one of the safest and most secure ways to regenerate session id's in user agent
cookies. If there is no conditional logic to determine when to regenerate the session id, then there are
no flaws in that logic. Although regenerating on every request prevents several possible avenues of
attack, not everyone wants the associated small performance and bandwidth cost. Thus, applications
commonly try to dynamically determine situations of greater risk, and only regenerate the session ids in
those situations. Whenever a website visitor's session's privileges are "escalated" (e.g. a visitor
re-authenticates their identity before editing their personal "profile"), or whenever a security
"sensitive" session parameter change occurs, consider using regenerateId()
to create a new
session id. If you call the rememberMe()
function, then don't use
regenerateId()
, since the former calls the latter. If a user has successfully logged into
your website, use rememberMe()
instead of regenerateId()
.
XSS problems occur frequently. Rather than expecting to never have a XSS problem with an application,
plan for it by following best practices to help minimize damage, if it occurs. With XSS, an attacker
does not need direct access to a victim's network traffic. If the victim already has a session cookie,
Javascript XSS might allow an attacker to read the cookie and steal the session. For victims with no
session cookies, using XSS to inject Javascript, an attacker could create a session id cookie on the
victim's browser with a known value, then set an identical cookie on the attacker's system, in order to
hijack the victim's session. If the victim visited an attacker's website, then the attacker can also
emulate most other identifiable characteristics of the victim's user agent. If your website has an XSS
vulnerability, the attacker might be able to insert an AJAX Javascript that secretly "visits" the
attacker's website, so that the attacker knows the victim's browser characteristics and becomes aware of
a compromised session at the victim website. However, the attacker can not arbitrarily alter the
server-side state of PHP sessions, provided the developer has correctly set the value for the
save_path
option.
By itself, calling Zend_Session_Core::regenerateId()
when the user's session is first used,
does not prevent session fixation attacks, unless you can distinguish between a session originated by an
attacker emulating the victim. At first, this might sound contradictory to previous statement above,
until we consider an attacker who first initiates a real session on your website. The session is "first
used" by the attacker, who then knows the result of the initialization (regenerateId()
).
The attacker then uses the new session id in combination with an XSS vulnerability, or injects the
session id via a link on the attacker's website (works if use_only_cookies = off
).
If you can distinguish between an attacker and victim using the same session id, then session hijacking can be dealt with directly. However, such distinctions usually involve some form of usability tradeoffs, because the methods of distinction are often imprecise. For example, if a request is received from an IP in a different country than the IP of the request when the session was created, then the new request probably belongs to an attacker. Under the following conditions, there might not be any way for a website application to distinguish between a victim and an attacker:
- attacker first initiates a session on your website to obtain a valid session id
- attacker uses XSS vulnerability on your website to create a cookie on the victim's browser with the same, valid session id (i.e. session fixation)
- both the victim and attacker originate from the same proxy farm (e.g. both are behind the same firewall at a large company, like AOL)
The sample code below makes it much harder for an attacker to know the current victim's session id, unless the attacker has already performed the first two steps above.
Ordinarily, sessions end when the user agent ends its "session", such as when an end user closes their
browser window. However, when a user logs in to your website, they might want their virtual session to last
for 24 hours, or even longer. Forum software commonly gives the user a choice for how long their session
should last. Use Zend_Session_Core::rememberMe()
to send an updated session cookie to the user
agent with a lifetime defaulting to remember_me_seconds
, which is set to 2 weeks, unless you
modify that value using setOptions()
. To help thwart session fixation/hijacking, use this
function when a user successfully authenticates and you application performs a "login".
This function complements rememberMe()
by changing the session cookie back to a lifetime ending
when the user agent ends its session (e.g. user closes their browser window).
Use this method to determine if a session already exists for the current user agent/request. It may be used before starting a session, and independently of all other Zend_Session and Zend_Session_Core methods.
Zend_Session_Core::destroy()
destroys all of the persistent data associated with the current
session. However, no variables in PHP are affected, so your namespaced sessions (instances of
Zend_Session
) remain readable. To complete a "logout", set the optional parameter to true
(default is true) to also delete the user agent's session id cookie. The optinal $readonly
parameter removes the ability for Zend_Session instances, and Zend_Session_Core methods to write to the
session data store (i.e. $_SESSION).
![]() |
Throws |
---|---|
By default, |
This method does absolutely nothing more than toggle a flag in Zend_Session_Core to prevent further writing
to the session data store (i.e. $_SESSION
). We are specifically requesting feedback on this
feature. Potential uses/abuses might include temporarily disabling the use of Zend_Session
instances or Zend_Session_Core
methods to write to the session data store, while execution is
transfered to view-related code. Attempts to perform actions involving writes via these instances or methods
will throw an error.
Shutdown the sesssion, close writing and detach $_SESSION from the back-end storage mechanism. This will complete the internal data transformation on this request. The optional $readonly boolean parameter can remove write access (i.e. throw error if any Zend_Session or Zend_Session_Core methods attempt writes).
![]() |
Throws |
---|---|
By default, |
This method sends an expired session id cookie, causing the client to delete the session cookie. Sometimes this technique is used to perform a client-side logout.
Most developers will find the default save handler sufficient. This method provides an object-oriented
wrapper for
session_set_save_handler()
.
Zend_Session uses this method to loosely couple instances with the Zend_Session_Core singleton via a form of dependency injection.
Use this method to determine if a session namespace exists, or if a particular index exists in a particular namespace.
![]() |
Throws |
---|---|
An error will be thrown if Zend_Session_Core is not marked as readable (e.g. before Zend_Session_Core has been started). |
Instead of creating a Zend_Session instance for a namespace, and iterating over its contents to unset each
entry, use namespaceUnset($namespace)
to efficiently unset (remove) an entire namespace and its
contents. As with all arrays in PHP, if a variable containing an array is unset, and the array contains
other objects, those objects will remain available, if they were also stored in other array/objects that
remain accessible via other variables. So do not expect namespaceUnset()
to actually do a
"deep" unsetting/deleting of the contents of the entries in the namespace. For a more detailed explanation,
please see
References Explained
in the PHP manual.
![]() |
Throws |
---|---|
An error will be thrown if the namespace is not writable (e.g. after |
Zend_Session uses this internal method to add entries to a namespace. This method might not remain public. If you have logical reasons to keep this method publicly accessible, instead of using Zend_Session, please provide feedback to the fw-auth@lists.zend.com mail list.
![]() |
Throws |
---|---|
An error will be thrown if Zend_Session_Core is not marked as readable (e.g. before Zend_Session_Core has been started). |
Zend_Session uses this internal method to get either the value of $name
in
$namespace
, or an array of the contents of $namespace
. This method might not
remain public. If you have logical reasons to keep this method publicly accessible, instead of using
Zend_Session, please provide feedback to the
fw-auth@lists.zend.com
mail list. Actually, all participation on any relevant topic is welcome :)
![]() |
Throws |
---|---|
An error will be thrown if Zend_Session_Core is not marked as readable (e.g. before Zend_Session_Core has been started). |
Use getIterator()
to obtain an iterable array containing the names of all namespaces.
Example 21.14. Unsetting All Namespaces
<?php $core = Zend_Session_Core::getInstance(); foreach(Zend_Session_Core::getIterator() as $space) { try { $core->namespaceUnset($space); } catch (Zend_Session_Exception $e) { return; // possible if Zend_Session_Core::stop() has been executed } } ?>
![]() |
Throws |
---|---|
An error will be thrown if Zend_Session_Core is not marked as readable (e.g. before Zend_Session_Core has been started). |