CSE 134A Lecture Notes, October 21, 2002

CSE134A LECTURE NOTES

October 21, 2002

ANNOUNCEMENTS

Today's handout is the article Session Handling with PHP 4 by Tobias Ratschiller, published at http://www.zend.com/zend/tut/session.php?print=1.

COOKIES

[These notes on cookies are adapted from the PHP manual.]

int setcookie (string name [, string value [, int expire [, string path [, string domain [, int secure]]]]])

This defines a cookie to be sent along with the rest of the header information. Cookies must be sent before any other headers are sent (this is a restriction of cookies, not PHP). This requires you to place calls to this function before any <html> or <head> tags.

All the arguments except the name argument are optional. If only the name argument is present, the cookie by that name will be deleted from the remote client. You may also replace any argument with an empty string ("") in order to skip that argument. The expire and secure arguments are integers and cannot be skipped with an empty string. Use a zero (0) instead. The expire argument is a regular Unix time integer as returned by the time() or mktime() functions. The secure indicates that the cookie should only be transmitted over a secure HTTPS connection.

Once the cookies have been set, they can be accessed on the next page load with the "autoglobal" array named $_COOKIE.

Common pitfalls:

If only the name argument is present, the cookie by that name will be deleted from the remote client.
Cookies will not become visible until the next loading of a page that the cookie should be visible for.
Cookies must be deleted with the same parameters as they were set with.

The text above is adapted from the PHP manual.

SESSION MANAGEMENT

The text here is taken from Session Handling with PHP 4 by Tobias Ratschiller, published at http://www.zend.com/zend/tut/session.php?print=1

The term "session" refers to the time that a user is at a particular web site. For example, a typical online shopping session might include logging in, putting an item into the shopping cart, going to the checkout page, entering address and credit card data, submitting the order, and closing the browser window.

Unfortunately, HTTP has no mechanism to maintain state: individual requests aren't related to each other. Therefore, the web server can't easily distinguish between single users and doesn't know about user sessions.

Session management is a server-side mechanism to save data about visits from the same user. PHP 4 includes native session management functions to ease the task of managing user sessions.

To associate session data with a user, you need a session identity number saved on the client, which the client sends to the server with each request.

STARTING A SESSION

A PHP 4 session is started either explicitly by session_start(), or implicitly by registering a variable for the session. Usually, you call session_start() at the top of each page, to make session variables available to your script. Then you register variables to the session later in the script.

When you start a session either way, the following happens:

PHP checks whether a valid session ID exists.
If there is no session ID, PHP creates a new ID.
If a valid ID exists, the frozen variables of that session are reactivated and introduced back to the global namespace.

Be sure you understand the general principle of what a session is. On the client side, the session id must be propagated from each web page to the next web page within the session. On the server side, the session id must be propagated from each script execution to the next script execution within the session.

SESSION VARIABLES

[As stated before, the information here is taken from Session Handling with PHP 4 by Tobias Ratschiller, available at http://www.zend.com/zend/tut/session.php?print=1]

Either the session_register() function, or assigning to an element of the array $_SESSION , creates a new global variable which is stored throughout the session. All variables you want to preserve across page requests must be registered. Don't mix both methods for registering session variables.

This is an example of a counter that increments for each page of a session. You would put this code in each script that might be executed as part of the session.

session_start();
print($_SESSION["counter"]);
$_SESSION["counter"]++;

Note that session_register() or $_SESSION takes a string that is the name of a variable as argument, not the variable itself.

It's as easy to use session variables in a script as it is to use GET/POST variables. If you register a variable named "foo" then$foois accessible automatically after calling session_start(). You can also register objects as session variables.

All registered variables are serialized after the request finishes.

PROPAGATING SESSION IDS

PHP sessions support the following methods of passing the session ID from one web page to another:

Cookies (default)
As GET variables placed by the script author in the URL
As GET variables by automatic URL rewriting

Cookies are the default way to pass the session ID between pages. With the second and third methods the URL is similar to

script.php?<session-name>=<session-id>.

You can create a URL like this explicitly using the PHP global constant named SID:

printf('<a href="script.php?%s">Link</a>', SID);

In the above, %s is a format that controls how the value ofSIDis printed.

With automatic URL rewriting, the session ID in the GET form is added automatically to all relative links within PHP-parsed pages (not to absolute links to external web sites).

Automatic URL rewriting should be used with caution on high-performance sites. PHP has to analyze whether each page contains relative links, then add the ID to the links. This introduces a performance penalty. Cookies are set only once, and avoid the overhead of URL rewriting.

ENDING A SESSION

Session ending is not automatic, because it is difficult for the system to tell when the user is finished with his/her session.

The programmer can force a session end with the command session_destroy().
The default cookie lifetime is 0, meaning that the cookie is deleted and the session ends when the user closes the browser.

The gc_maxlifetime configuration directive specifies how long after the last access to each session its data is destroyed. This happens even if the cookie still exists on the client side.

SECURITY

[From http://www.php.net/manual/en/ref.session.php.] Using sessions, does not mean you can be absolutely sure that session data can only be viewed by that user.

Therefore, when dealing with sensitive information, there should always be additional methods to decide whether it is a valid session. Sessions are not completely reliable as a secure authentication mechanism.

Sessions rely on the session ID, meaning an attacker can 'steal' a session by stealing the session ID. This can be made harder by using a cookie, but security then relies on the user closing all browser windows, to expire the session cookie. Even then session cookies can be sniffed on a network or logged by a proxy server.