From Web Services Wiki
There are a number of measures that may be taken to ensure that the cookies and sessions you use are not visible to other applications.
If you have access to MySQL, storing your sessions in a database is the best option. Visit Stanford MySQL Service to register your group, department, or service for database access. At this time Stanford does not support MySQL for individual user accounts.
MySQL-based sessions ensure privacy by storing all session data in a secure database. We suggest always storing sessions in a database on the Stanford domain for many reasons. Read more about how to set up and why to use MySQL-based PHP Sessions.
Each session is indexed by its name (which defaults to
PHPSESSID). If you don't have access to a MySQL database, make sure to use a unique name for your PHP sessions, since they are otherwise shared throughout the domain. To change the session name for your site or application, put the following line of code in its configuration file.
// Using ini_set ini_set("session.name", "new_session_name"); // Alternatively, use session_name $old_name = session_name("new_session_name");
Some open source web packages already have an option to change the name of the session in their configuration files. Make use of these features whenever possible.
Restricting the cookie to a certain path
By default, when using the
setcookie function, each cookie is valid within the directory in which it was created. For instance, if a script is located at
stanford.edu/~your_sunetid/cgi-bin/test/, the cookie will be valid in "test" but not in any directories below it. It is possible to override this functionality by setting the path manually. When cookies must be accessed in other paths, which is often the case, it may be tempting to set the path to "/", which makes the cookie visible to the entire domain. We advise against this and suggest setting the path to your application's root directory.
// Restrict cookie path // This is a web path, not a local path, so if you want to restrict cookies to your application directory // and your URL is http://www.stanford.edu/group/my_group_name/myapp/ // then set the cookie path to "/group/my_group_name/myapp/" (cut off the domain) define("COOKIE_PATH", "/~your_sunetid/cgi-bin/myapp/"); // Cookies expire in one month define("COOKIE_EXPIRATION", time()+60*60*24*30); // Set the cookie setcookie("username", "john_doe", COOKIE_EXPIRATION, COOKIE_PATH);
Why should I be concerned?
Sites hosted at Stanford share the stanford.edu domain. Sessions and cookies are accessible to all sites on the domain if precautions are not taken. Imagine a scenario where two groups install open source blogging software which use the same name for sessions in their respective paths. When the administrator is authenticated, a session variable called "admin" is set to true. The administrator may then gain access to both sites by logging into just one. This example is one of many possible problems that may arise from not securing your sessions by using unique names or storing them in a secure database.