312 Part II: Developing an Ajax Library^
Considering all of the problems from the previous section, we need to assure you that
logging out is also easy, simply remove the session variables and bounce the user out of the
application as shown in logoutsession.php:<?php
session_start();
header("Cache-Control: no-cache");
header("Pragma: no-cache");
unset($_SESSION["loggedin"]);
unset($_SESSION["username"]);
header("Location: ch7.html");
?>You can play with the complete example at http://ajaxref.com/ch7/authenticationsession.html.
Given the lack of headaches presented, you can see why many developers opt for
custom authentication: it can be configured and works reliably as long as the user accepts
cookies. However, we do need to make some important notes. First, even though the
password is protected with md5, a snooper can simply take the md5 version and send it to
the server themselves. Even though they can’t decode it as before, thus never learning your
true password, they can still copy the transmitted hash value to gain access to the protected
resource. Second, the transmission is still observable, so SSL is still likely in order. Finally,
once logged in, the session cookie issued is of particular interest to a hacker. If they can
discover and copy this value, they can copy it and hijack the session for their own devices.
But that can never happen...or can it?Cross-Site Scripting
JavaScript can access cookie values via document.cookie but, as restricted by the cookie
specification and browsers, a cookie value is only shown for the domain in play. In other
words, site example.com can only access cookies from example.com. While this is fine and
well, what happens if the site example.com has been compromised? Certainly your cookies
can be exposed. You might say who cares? If it is compromised, users are in trouble anyway
because bad guys control the server. Well, hackers don’t need to go the extreme of controlling
a site to gain access to user’s cookies if the site in question is susceptible to a compromise
called cross-site scripting or more simply XSS.
The basic idea of XSS is that a user visits a site and executes JavaScript written by a
hacker within the user’s browser. That’s a bit broad of a definition, so let’s illustrate the idea
with an example. Say there is a blog or message board you like to visit where users can post
comments. Now let’s say this site allows comments to contain XHTML markup; thus, it is
likely susceptible to XSS. A malcontent individual comes to your favorite board and posts
a message in the box like so: