Apache HTTP Server Version 2.4
Description: | Session support |
---|---|
Status: | Extension |
Module Identifier: | session_module |
Source File: | mod_session.c |
Compatibility: | Available in Apache 2.3 and later |
The session modules make use of HTTP cookies, and as such can fall victim to Cross Site Scripting attacks, or expose potentially private information to clients. Please ensure that the relevant risks have been taken into account before enabling the session functionality on your server.
This module provides support for a server wide per user session interface. Sessions can be used for keeping track of whether a user has been logged in, or for other per user information that should be kept available across requests.
Sessions may be stored on the server, or may be stored on the
browser. Sessions may also be optionally encrypted for added security.
These features are divided into several modules in addition to
mod_session
; mod_session_crypto
,
mod_session_cookie
and mod_session_dbd
.
Depending on the server requirements, load the appropriate modules
into the server (either statically at compile time or dynamically
via the LoadModule
directive).
Sessions may be manipulated from other modules that depend on the session, or the session may be read from and written to using environment variables and HTTP headers, as appropriate.
At the core of the session interface is a table of key and value pairs that are made accessible across browser requests. These pairs can be set to any valid string, as needed by the application making use of the session.
The "session" is a application/x-www-form-urlencoded string containing these key value pairs, as defined by the HTML specification.
The session can optionally be encrypted and base64 encoded before being written to the storage mechanism, as defined by the administrator.
The session interface is primarily developed for the use by other
server modules, such as mod_auth_form
, however CGI
based applications can optionally be granted access to the contents
of the session via the HTTP_SESSION environment variable. Sessions
have the option to be modified and/or updated by inserting an HTTP
response header containing the new session parameters.
Apache can be configured to keep track of per user sessions stored on a particular server or group of servers. This functionality is similar to the sessions available in typical application servers.
If configured, sessions are tracked through the use of a session ID that is stored inside a cookie, or extracted from the parameters embedded within the URL query string, as found in a typical GET request.
As the contents of the session are stored exclusively on the server, there is an expectation of privacy of the contents of the session. This does have performance and resource implications should a large number of sessions be present, or where a large number of webservers have to share sessions with one another.
The mod_session_dbd
module allows the storage of user
sessions within a SQL database via mod_dbd
.
In high traffic environments where keeping track of a session on a server is too resource intensive or inconvenient, the option exists to store the contents of the session within a cookie on the client browser instead.
This has the advantage that minimal resources are required on the server to keep track of sessions, and multiple servers within a server farm have no need to share session information.
The contents of the session however are exposed to the client, with a
corresponding risk of a loss of privacy. The
mod_session_crypto
module can be configured to encrypt the
contents of the session before writing the session to the client.
The mod_session_cookie
allows the storage of user
sessions on the browser within an HTTP cookie.
Creating a session is as simple as turning the session on, and deciding
where the session will be stored. In this example, the session will be
stored on the browser, in a cookie called session
.
Session On SessionCookieName session path=/
The session is not useful unless it can be written to or read from. The
following example shows how values can be injected into the session through
the use of a predetermined HTTP response header called
X-Replace-Session
.
Session On SessionCookieName session path=/ SessionHeader X-Replace-Session
The header should contain name value pairs expressed in the same format as a query string in a URL, as in the example below. Setting a key to the empty string has the effect of removing that key from the session.
#!/bin/bash echo "Content-Type: text/plain" echo "X-Replace-Session: key1=foo&key2=&key3=bar" echo env
If configured, the session can be read back from the HTTP_SESSION
environment variable. By default, the session is kept private, so this
has to be explicitly turned on with the
SessionEnv
directive.
Session On SessionEnv On SessionCookieName session path=/ SessionHeader X-Replace-Session
Once read, the CGI variable HTTP_SESSION
should contain
the value key1=foo&key3=bar
.
Using the "show cookies" feature of your browser, you would have seen a clear text representation of the session. This could potentially be a problem should the end user need to be kept unaware of the contents of the session, or where a third party could gain unauthorised access to the data within the session.
The contents of the session can be optionally encrypted before being
placed on the browser using the mod_session_crypto
module.
Session On SessionCryptoPassphrase secret SessionCookieName session path=/
The session will be automatically decrypted on load, and encrypted on save by Apache, the underlying application using the session need have no knowledge that encryption is taking place.
Sessions stored on the server rather than on the browser can also be
encrypted as needed, offering privacy where potentially sensitive
information is being shared between webservers in a server farm using
the mod_session_dbd
module.
The HTTP cookie mechanism also offers privacy features, such as the ability to restrict cookie transport to SSL protected pages only, or to prevent browser based javascript from gaining access to the contents of the cookie.
Some of the HTTP cookie privacy features are either non-standard, or
are not implemented consistently across browsers. The session modules
allow you to set cookie parameters, but it makes no guarantee that privacy
will be respected by the browser. If security is a concern, use the
mod_session_crypto
to encrypt the contents of the session,
or store the session on the server using the