1 Session management and maintaining state

Session management or state maintenance poses a challenge for any server-side web language. This is because, in contrast to stand-alone applications, server-side applications transfer data between servers and clients. A server-side application does not have full control over the data at the client's computer. A client can delete, modify or add to any data. Therefore client-data cannot be trusted.

Sessions are created to minimise the risk of data corruption. All user data is stored on the server and associated with a session ID. Data retrieval is based on the session ID. A security check must be performed on any data, which a user enters, before the data is stored on the server. It is not necessary to perform security checks on data that is retrieved from the server. This is in contrast to PHP applications without sessions: in that case a security check must be performed on user data every time the data is used!

The session IDs should be generated by the server and should be long and complicated enough to deter users from manual tampering with the IDs. Session IDs are passed from page to page either

  • by using hidden HTML form text or
  • by using the query string or
  • by using cookies (on the client computer).

    The user data, which is associated with a session ID can be stored on the server

  • in a file
  • in a database.

    This approach reduces the number of security checks that must be performed on user data. Because users can modify their cookies (or disallow cookies) and can modify hidden HTML form text or query strings, it is possible for a hacker to break into another user's session. This problem affects all server-side web languages, not just Perl and PHP. For highly sensitive applications, other measures, such as encryption (SSL) and password protection must be added.

    1.1 Hidden Text - Exercise

    1) Create a form that asks a user for his/her name and some comments. Then create two PHP scripts that create a response. The first script displays the information which the user has submitted ("Hello $name. These are your comments: $comments") and asks the user whether he/she really wants to submit the information. The second script is invoked by the first one and displays "Thank you $name. Your comments have been submitted: $comments".

    To implement this add a form and hidden tags to the first PHP script, such as

    <input type='hidden' name='hiddenname' value=\"$name\">
    <input type='hidden' name='hiddencomments' value=\"$comments\">

    The second PHP script retrieves these strings via

    $name = $_REQUEST['hiddenname'];
    $comments = $_REQUEST['hiddencomments'];

    1.2 Cookies - Exercise

    2) Use a cookie instead of hidden text in the previous exercise.

    The following code in the first PHP script sets a cookie.

    $cookiedata = $name."|".$comments;
    setcookie("nameandcomments", $cookiedata, time()+3600);

    Note: the cookie must be set at the very beginning of the PHP script before any other HTML code or header information is generated. Even blank space at the beginning of the file can create a problem!!!

    The second PHP script retrieves the cookie similarly to retrieving parameters:

    $array = preg_split('/\|/',$_COOKIE['nameandcomments']);
    $name = $array[0];
    $comments = $array[1];

    More information about PHP cookies.

    1.3 Using Sessions

    3) Use PHP session handling functions for the previous exercise. (In particular, have a look at the examples for session_start or this example.)

    1.4 Hit Counter - Exercise

    4) Create a file that contains only the number "0". Your PHP script must open that file for reading; read the first line of the file into a scalar variable; increase the number by one; close the file; open the file again for writing (not appending); write the number to the file; close the file.

    (On Unix: because of permissions, first, you need to create and save the file manually. Then you need to change the file permissions to 666 on the command-line.)

    2 Optional: Password protected pages

    Access to web sites on an Apache Server can be controlled using the HTACCESS files. Two files are involved in access control: a .www-password file is created and saved in a directory above the public_html directory. Any directory under the public_html directory can then be protected by saving a .htaccess file in the directory. It should be noted that htaccess only encrypts the password but not the pages. Therefore it does not provide high level security. Furthermore, htaccess does not protect your files from being viewed by other Unix users on the same computer.

    2.1 Optional exercise

    Create a password protected directory under your public_html directory. Specific instructions:
  • Go to your top level directory and type htpasswd ~/.www-password remoteuser at the Unix prompt. You can replace remoteuser with a login name you want to use for your pages. Type in a password when prompted. Note that this should be a new password, different from any password you are using for other purposes. The .www-password file must be readable by others.
  • Create a new directory under public_html. Go to the directory. Create a file called .htaccess with the following content:
    AuthType Basic
    AuthName "Password Required"
    AuthUserFile /home/yourmatricnumber/.www-password
    AuthGroupFile /dev/null
    <Limit GET POST>
    require user remoteuser
    </Limit>
    where yourmatricnumber is your matric number and remoteuser is the same name you used above.
  • Change the .htaccess file to readable (chmod 644 .htaccess)
  • If you view any html from that directory through your browser, you should now be prompted for a username and password.