Tài liệu Advanced PHP Programming- P8 pdf

To utilize your library, you wrap it in a function that you call at the top of everypage: function check_auth { try { $cookie = new Cookie; $cookie->validate; } catch AuthException $e {

Ironically, a tuned system makes dictionary attacks even easier for the cracker At a ous job, I was astounded to discover a cracker executing a dictionary attack at more than 100 attempts per second At that rate, he could attempt an entire 50,000-word dic-tionary in under 10 minutes.

previ-There are two solutions to protecting against password attacks, although neither is ribly effective:

ter-n Create “good” passwords

n Limit the effectiveness of dictionary attacks

What is a ”good” password? A good password is one that cannot be guessed easily byusing automated techniques A “good” password generator might look like this:

function random_password($length=8) {

$str = ‘’ ; for($i=0; $i<$length; $i++) {

$str = chr(rand(48,122));

} return $str;

}

This generates passwords that consist of random printable ASCII characters.They are alsovery difficult to remember.This is the key problem with truly random password genera-tors: People hate the passwords they generate.The more difficult a password is to remem-ber, the more likely a person is to put it on a sticky note on his or her monitor or in atext file or an email message

A common approach to this problem is to put the burden of good password tion on the user and enforce it with simple rules.You can allow the user to select his orher own password but require that password to pass certain tests.The following is a sim-ple password validator for this scenario:

genera-function good_password($password) { if(strlen($password) < 8) { return 0;

} if(!preg_match( “ /\d/ ” , $password)) { return 0;

} if(!preg_match( “ /[a-z]/i ” , $password)) { return 0;

} }

This function requires a password to be at least eight characters long and contain bothletters and numbers

A more robust function might check to ensure that when the numeric characters areremoved, what is left is not a single dictionary word or that the user’s name or address is

not contained in the password.This approach to the problems is one of the key tenets ofconsulting work:When a problem is difficult, make it someone else’s problem.

Generating a secure password that a user can be happy with is difficult It is much easier

to detect a bad password and prevent the user from choosing it

The next challenge is to prevent dictionary attacks against the authentication system

Given free reign, a cracker running a dictionary attack will always compromise users

No matter how good your rules for preventing bad passwords, the space of comprehensible passwords is small

human-One solution is to lock down an account if it has a number of consecutive failuresagainst it.This solution is easy enough to implement.You can modify the original

check_credentialsfunction to only allow for a fixed number of failures before theaccount is locked:

function check_credentials($name, $password) {

$dbh = new DB_Mysql_Prod();

$cur = $dbh->execute( “

SELECT userid, password FROM

users WHERE username = ‘ $name ’

AND failures < 3 ” );

$row = $cur->fetch_assoc();

if($row) { if($password == $row[ ‘ password ’ ]) { return $row[ ‘ userid ’ ];

} else {

$cur = $dbh->execute( “

UPDATE users SET failures = failures + 1, last_failure = now() WHERE

username = ‘ $name ’” );

} } throw new AuthException( “ user is not authorized ” );

login failures to IP addresses to partially rectify this concern Login security is an endlessbattle.There is no such thing as an exploit-free system It’s important to weigh thepotential risks against the time and resources necessary to handle a potential exploit.The particular strategy you use can be as complex as you like Some examples are nomore than three login attempts in one minute and no more than 20 login attempts in

a day

Protecting Passwords Against Social Engineering

Although it’s not really a technical issue, we would be remiss to talk about login security

without mentioning social engineering attacks Social engineering involves tricking a user

into giving you information, often by posing as a trusted figure Common social neering exploits include the following:

engi-n Posing as a systems administrator for the site and sending email messages that askusers for their passwords for “security reasons”

n Creating a mirror image of the site login page and tricking users into attempting

to log in

n Trying some combination of the two

It might seem implausible that users would fall for these techniques, but they are verycommon Searching Google for scams involving eBay turns up a plethora of suchexploits

It is very hard to protect against social engineering attacks.The crux of the problem isthat they are really not technical attacks at all; they are simply attacks that involve dupingusers into making stupid choices.The only options are to educate users on how and whyyou might contact them and to try to instill in users a healthy skepticism about relin-quishing their personal information

Good luck, you’ll need it

JavaScript Is a Tool of Evil

The following sections talk about a number of session security methods that involve cookies Be aware that client-side scripting languages such as JavaScript have access to users’ cookies If you run a site that allows users to embed arbitrary JavaScript or CSS in a page that is being served by your domain (that is, a domain that has access to your cookies), your cookies can easily be hijacked JavaScript is a community-site crack- er’s dream because it allows for easy manipulation of all the data you send to the client.

This category of attack is known as cross-site scripting In a cross-site scripting attack, a malicious user uses

some sort of client-side technology (most commonly JavaScript, Flash, and CSS) to cause you to download malicious code from a site other than the one you think you are visiting.

Maintaining Authentication: Ensuring That You Are Still Talking to the Same Person

Trying to create a sitewide authentication and/or authorization system without cookies

is like cooking without utensils It can be done to prove a point, but it makes life cantly harder and your query strings much uglier It is very difficult to surf the Webthese days without cookies enabled All modern browsers, including the purely text-based ones, support cookies Cookies provide sufficient benefit that it is worth not sup-porting users who refuse to use them

signifi-A conversation about ways to tie state between requests is incomplete without a cussion of the pitfalls.The following sections cover commonly utilized but flawed andineffective ways to maintain state between requests

dis-Checking That $_SERVER[REMOTE_IP] Stays the Same

Relying on a user’s IP address to remain constant throughout his or her session is a sic pitfall; an attribute that many people think stays constant across requests as the user’sInternet connection remains up In reality, this method yields both false-positives andfalse-negatives Many ISPs use proxy servers to aggressively buffer HTTP requests tominimize the number of requests for common objects If you and I are using the sameISP and we both request foo.jpgfrom a site, only the first request actually leaves theISP’s network.This saves considerable bandwidth, and bandwidth is money

clas-Many ISPs scale their services by using clusters of proxy servers.When you surf theWeb, subsequent requests may go through different proxies, even if the requests are onlyseconds apart.To the Web server, this means that the requests come from different IPaddresses, meaning that a user’s $_SERVER[ ‘ REMOTE_IP ’ ]address can (validly) changeover the course of a session.You can easily witness this behavior if you inspect inboundtraffic from users on any of the major dial-up services

The negative renders this comparison useless, but it’s worth noting the positive as well Multiple users coming from behind the same proxy server have the same

false-$_SERVER[ ‘ REMOTE_IP ’ ]setting.This also holds true for users who come through thesame network translation box (which is typical of many corporate setups)

$_SERVER[ ‘ USER_AGENT ’ ]returns the string that the browser identifies itself with in therequest For example, this is the browser string for my browser:

Mozilla/4.0 (compatible; MSIE 5.21; Mac_PowerPC)

which is Internet Explorer 5.2 for Mac OS X In discussions about how to make PHPsessions more secure, a proposal has come up a number of times to check that

$_SERVER[ ‘ USER_AGENT ’ ]stays the same for a user across subsequent requests

Unfortunately, this falls victim to the same problem as $_SERVER[ ‘ REMOTE_IP ’ ] ManyISP proxy clusters cause different User Agent strings to be returned across multiplerequests

Using Unencrypted Cookies

Using unencrypted cookies to store user identity and authentication information is like abar accepting hand-written vouchers for patrons’ ages Cookies are trivial for a user toinspect and alter, so it is important that the data in the cookie be stored in a format inwhich the user can’t intelligently change its meaning (You’ll learn more on this later inthis chapter.)

Things You Should Do

Now that we’ve discussed things we should not use for authentication, let’s examinethings that are good to include

Themcryptextension provides access to a large number of proven cryptographicalgorithms Because you need to have both the encryption and decryption keys on theWeb server (so you can both read and write cookies), there is no value in using an asym-metric algorithm.The examples here use the blowfish algorithm; but it is easy to shift to

an alternative cipher

Using Expiration Logic

You have two choices for expiring an authentication: expiration on every use and ration after some period of time

expi-Expiration on Every Request

Expiration on every request works similarly to TCP A sequence is initiated for everyuser, and the current value is set in a cookie.When the user makes a subsequent request,that sequence value is compared against the last one sent If the two match, the request isauthenticated.The next sequence number is then generated, and the process repeats.Expiration on every request makes hijacking a session difficult but nowhere nearimpossible If I intercept the server response back to you and reply by using that cookiebefore you do, I have successfully hijacked your session.This might sound unlikely, butwhere there is a gain to be had, there are people who will try to exploit the technology.Unfortunately, security and usability are often in conflict with one another Creating asession server that cannot be hijacked is close to impossible

Using a sequence to generate tokens and changing them on every request also consumes significant resources Not only is there the overhead of decrypting and re-encrypting the cookie on every request (which is significant), you also need a means tostore the current sequence number for each user to validate their requests In a multi-server environment, this needs to be done in a database.That overhead can be very high.

For the marginal protection it affords, this expiration scheme is not worth the trouble

Expiration After a Fixed Time

The second option for expiring an authentication is to expire each cookie every fewminutes.Think of it as the time window on the lift ticket.The pass works for an entireday without reissue.You can write the time of issuance in the cookie and then validatethe session against that time.This still offers marginal hijack protection because thecookie must be used within a few minutes of its creation In addition, you gain the fol-lowing:

n No need for centralized validation—As long as the clocks on all machines arekept in sync, each cookie can be verified without checking any central authority

n Reissue cookies infrequently—Because the cookie is good for a period of time,you do not need to reissue it on every request.This means that you can eliminatehalf of the cryptographic work on almost every request

Collecting User Identity Information

This is hard to forget but still important to mention:You need to know who a cookieauthenticates A nonambiguous, permanent identifier is best If you also associate asequence number with a user, that works as well

Collecting Versioning Information

A small point to note: Any sort of persistent information you expect a client to giveback to you should contain version tags.Without versioning information in your cook-ies, it is impossible to change cookie formats without causing an interruption of service

At best, a change in cookie format will cause everyone surfing the site to have to log inagain At worst, it can cause chronic and hard-to-debug problems in the case where asingle machine is running an outdated version of the cookie code Lack of versioninginformation leads to brittle code

Logging Out

This is not a part of the cookie itself, but it’s a required feature:The user needs to beable to end his or her session Being able to log out is a critical privacy issue.You canimplement the logout functionality by clearing the session cookie

A Sample Authentication Implementation

Enough talk Let’s write some code! First you need to settle on a cookie format Based

on the information in this chapter, you decide that what you want would be fulfilled bythe version number $version, issuance timestamp $created, and user’s user ID

$userid:

<?php require_once ‘ Exception.inc ’ ; class AuthException extends Exception {}

class Cookie { private $created;

static $cookiename = ‘ USERAUTH ’ ; static $myversion = ‘ 1 ’ ; // when to expire the cookie static $expiration = ‘ 600 ’ ; // when to reissue the cookie static $warning = ‘ 300 ’ ; static $glue = ‘ | ’ ;

public function _ _construct($userid = false) {

$this->td = mcrypt_module_open ($cypher, ‘’ , $mode, ‘’ );

if($userid) {

$this->userid = $userid;

return;

} else { if(array_key_exists(self::$cookiename, $_COOKIE)) {

$buffer = $this->_unpackage($_COOKIE[self::$cookiename]);

} else { throw new AuthException( “ No Cookie ” );

}

} } public function set() {

$cookie = $this->_package();

set_cookie(self::$cookiename, $cookie);

} public function validate() { if(!$this->version || !$this->created || !$this->userid) { throw new AuthException( “ Malformed cookie ” );

}

if ($this->version != self::$myversion) { throw new AuthException( “ Version mismatch ” );

} private function _package() {

$parts = array(self::$myversion, time(), $this->userid);

$cookie = implode($glue, $parts);

return $this->_encrypt($cookie);

} private function _unpackage($cookie) {

throw new AuthException();

} } private function _encrypt($plaintext) {

$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);

mcrypt_generic_init ($this->td, $this->key, $iv);

$crypttext = mcrypt_generic ($this->td, $plaintext);

mcrypt_generic_deinit ($this->td);

return $iv.$crypttext;

} private function _decrypt($crypttext) {

$ivsize = mcrypt_get_iv_size($this->td);

$iv = substr($crypttext, 0, $ivsize);

$crypttext = substr($crypttext, $ivsize);

mcrypt_generic_init ($this->td, $this->key, $iv);

$plaintext = mdecrypt_generic ($this->td, $crypttext);

mcrypt_generic_deinit ($this->td);

return $plaintext;

} private function _reissue() {

$this->created = time();

} }

?>

This is a relatively complex class, so let’s start by examining its public interface If

Cookie’s constructor is not passed a user ID, it assumes that you are trying to read fromthe environment; so it attempts to read in and process the cookie from $_COOKIE.Thecookie stored as $cookiename(in this case,USERAUTH) If anything goes wrong withaccessing or decrypting the cookie, the constructor throws an AuthExceptionexception

AuthExceptionis a simple wrapper around the generic Exception class:

class AuthException extends Exception {}

You can rely on exceptions to handle all our authentication errors

After you instantiate a cookie from the environment, you might want to call

validate()on it.validate()checks the structure of the cookie and verifies that it isthe correct version and is not stale (It is stale if it was created more than $expiration

seconds ago.) validate()also handles resetting the cookie if it is getting close to ration (that is, if it was created more than $warningseconds ago) If you instantiate acookie with a user ID, then the class assumes that you are creating a brand new Cookie

expi-object, so validation of an existing cookie isn’t required

The public method set assembles, encrypts, and sets the cookie.You need this to allowcookies to be created initially Note that you do not set an expiration time in the cookie:

Internally, you have some helper functions._packageand_unpackageuseimplode

andexplodeto turn the array of required information into a string and vice versa

_encryptand_decrypthandle all the cryptography._encryptencrypts a plain-textstring by using the cipher you specified in the class attributes (blowfish) Conversely,

_decrypt decrypts an encrypted string and returns it

An important aspect to note is that you use this:

$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);

to create the “initial vector,” or seed, for the cryptographic functions.You then prependthis to the encrypted string It is possible to specify your own initial vector, and manydevelopers mistakenly choose to fix both their key and their initial vector in their cryptolibraries.When using a symmetric cipher with a fixed key in CBC (Cypher BlockChaining), CFB (Cypher Feedback), or OFB (Output Feedback) mode, it is critical touse a random initial vector; otherwise, your cookies are open to cryptographic attack

This is absolutely critical in CFB and OFB modes and somewhat less so in CBF mode

To utilize your library, you wrap it in a function that you call at the top of everypage:

function check_auth() { try {

$cookie = new Cookie();

$cookie->validate();

} catch (AuthException $e) { header( “ Location: /login.php?originating_uri= ” $_SERVER[ ‘ REQUEST_URI ’ ]);

exit;

} }

If the user’s cookie is valid, the user continues on; if the cookie is not valid, the user isredirected to the login page

If the user’s cookie does not exist or if there are any problems with validating it, theuser is issued an immediate redirect to the login page.You set the $_GETvariable

originating_uriso that you can return the user to the source page

login.phpis a simple form page that allows the user to submit his or her usernameand password If this login is successful, the user’s session cookie is set and the user isreturned to the page he or she originated from:

<?php require_once ‘ Cookie.inc ’ ; require_once ‘ Authentication.inc ’ ; require_once ‘ Exception.inc ’ ;

$name = $_POST[ ‘ name ’ ];

$password = $_POST[ ‘ password ’ ];

$uri = $_REQUEST[ ‘ originating_uri ’ ];

if(!$uri) {

$uri = ‘ / ’ ; }

try {

$userid = Authentication::check_credentials ($name, $password);

$cookie = new Cookie($userid);

$cookie->set();

header( “ Location: $uri ” );

exit;

} catch (AuthException $e) {

?>

<html>

<title> Login </title>

<body>

<form name=login method=post>

Username: <input type= ” text ” name= ” name ” ><br>

Password: <input type= ” password ” name= ” name ” ><br>

<input type= ” hidden ” name= ” originating_uri ”

value= ” <?= $_REQUEST[ ‘ originating_uri ’ ] ?>

<input type=submit name=submitted value= ” Login ” >

</form>

</body>

</html>

<?php }

?>

You can use the same check_credentialsfrom earlier in this chapter as your means ofauthenticating a user from his or her username/password credentials:

class Authentication { function check_credentials($name, $password) {

$dbh = new DB_Mysql_Prod();

$cur = $dbh->prepare( “

SELECT userid FROM users WHERE username = :1 AND password = :2 ” )->execute($name, md5($password));

$row = $cur->fetch_assoc();

if($row) {

$userid = $row[ ‘ userid ’ ];

} else { throw new AuthException( “ user is not authorized ” );

} return $userid;

} }

Note that you do not store the user’s password in plaintext, but instead store an MD5hash

of it.The upside of this is that even if your database is compromised, your user passwordswill remain safe.The downside (if you can consider it as such) is that there is no way torecover a user password; you can only reset it

If you need to change the authentication method (say, to password lookup, Kerberos,

or LDAP), you only need to change the function authenticate.The rest of the structure runs independently

infra-Single Signon

To extend our skiing metaphor, a number of ski resorts have partnerships with othermountains such that a valid pass from any one of the resorts allows you to ski at any ofthem.When you show up and present your pass, the resort gives you a lift ticket for itsmountain as well.This is the essence of single signon

Single Signon’s Bad Rep

Single signon has received a lot of negative publicity surrounding Microsoft’s Passport The serious questions surrounding Passport isn’t whether single signon is good or bad; they are security concerns regarding using

a centralized third-party authenticator This section doesn’t talk about true third-party authenticators but about authentication among known trusted partners.

Many companies own multiple separately branded sites (different sites, different domains,same management) For example, say you managed two different, separately branded,stores, and you would like to be able to take a user’s profile information from one storeand automatically populate his or her profile information in the other store so that theuser does not have to take the time to fill out any forms with data you already have

Cookies are tied to a domain, so you cannot naively use a cookie from one domain toauthenticate a user on a different domain

As shown in Figure 13.1, this is the logic flow the first time a user logs in to any ofthe shared-authorization sites:

client web browser

web browser www.example.foo

authentication server www.singlesignon.foo

3 4 5 6 8 7 2 1

Figure 13.1 Single signon initial login.

When the user logs in to the system, he or she goes through the following steps:

1 The client makes a query to the Web server www.example.com

2 The page detects that the user is not logged in (he or she has no valid sessioncookie for www.example.com) and redirects the user to a login page at

www.singlesignon.com In addition, the redirect contains a hidden variable that is

an encrypted authorization request certifying the request as coming from

www.example.com

3 The client issues the request to www.singlesignon.com’s login page

4 www.singlesignon.compresents the user with a login/password prompt

5 The client submits the form with authorization request to the authentication server

6 The authentication server processes the authentication request and generates aredirect back to www.example.com, with an encrypted authorization response.Theauthentication server also sets a session cookie for the user

7 The user’s browser makes one final request, returning the authentication responseback to www.example.com

8 www.example.comvalidates the encrypted authentication response issued by theauthentication server and sets a session cookie for the user

On subsequent login attempts to any site that uses the same login server, much of thelogic is short-circuited Figure 13.2 shows a second login attempt from a different site

Figure 13.2 Single signon after an initial attempt.

The beginning of the process is the same as the one shown in Figure 13.1, except thatwhen the client issues a request to www.singlesignon.com, it now presents the serverwith the cookie it was previously issued in step 6 Here’s how it works:

client web browser

web browser www.example.foo

authentication server www.singlesignon.foo

3 4

6 5 2 1

1 The client makes a query to the Web server www.example.com.

2 The page detects that the user is not logged in (he or she has no valid sessioncookie for www.example.com) and redirects the user to a login page at

www.singlesignon.com In addition, the redirect contains a hidden variable that is

an encrypted authorization request certifying the request as coming from

www.example.com

3 The client issues the request to www.singlesignon.com’s login page

4 The authentication server verifies the user’s singlesignonsession cookie, issuesthe user an authentication response, and redirects the user back to

A Single Signon Implementation

Here is a sample implementation of a single signon system Note that it provides tions for both the master server and the peripheral servers to call Also note that it pro-vides its ownmcryptwrapper functions If you had an external mcryptwrapper librarythat you already used, you could substitute that:

func-class SingleSignOn { protected $cypher = ‘ blowfish ’ ; protected $mode = ‘ cfb ’ ; protected $key = ‘ choose a better key ’ ; protected $td;

protected $glue = ‘ | ’ ; protected $clock_skew = 60;

$this->td = mcrypt_module_open ($this->cypher, ‘’ , $this->mode, ‘’ );

} public function generate_auth_request() {

$parts = array($this->myversion, time(),

} } public function generate_auth_response() {

$parts = array($this->myversion, time(), $this->userid);

$plaintext = implode($this->glue, $parts);

} return $this->userid;

}

protected function _encrypt($plaintext) {

$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);

mcrypt_generic_init ($this->td, $this->key, $iv);

$crypttext = mcrypt_generic ($this->td, $plaintext);

mcrypt_generic_deinit ($this->td);

return $iv.$crypttext;

}

protected function _decrypt($crypttext) {

$ivsize = mcrypt_get_iv_size($this->td);

$iv = substr($crypttext, 0, $ivsize);

$crypttext = substr($crypttext, $ivsize);

mcrypt_generic_init ($this->td, $this->key, $iv);

$plaintext = mdecrypt_generic ($this->td, $crypttext);

mcrypt_generic_deinit ($this->td);

return $plaintext;

} }

SingleSignOnis not much more complex than Cookie.The major difference is that youare passing two different kinds of messages (requests and responses), and you will besending them as query-string parameters instead of cookies.You have a generate and aprocess method for both request and response.You probably recognize our friends

_encryptand_decryptfrom Cookie.inc—they are unchanged from there

To utilize these, you first need to set all the parameters correctly.You could simplyinstantiate a SingleSignOnobject as follows:

<?php include_once ‘ SingleSignOn.inc ’ ;

$client = new SingleSignOn();

Now you change your general authentication wrapper to check not only whether theuser has a cookie but also whether the user has a certified response from the authentica-tion server:

function check_auth() { try {

$cookie = new Cookie();

$cookie->validate();

} catch(AuthException $e) { try {

$client = new SingleSignOn();

$client->process_auth_response($_GET[ ‘ response ’ ]);

$cookie->userid = $client->userid;

} catch(SignOnException $e) {

$client->originating_uri = $_SERVER[ ‘ REQUEST_URI ’ ];

$client->generate_auth_request();

// we have sent a 302 redirect by now, so we can stop all other work exit;

} } }

The logic works as follows: If the user has a valid cookie, he or she is immediately passedthrough If the user does not have a valid cookie, you check to see whether the user iscoming in with a valid response from the authentication server If so, you give the user alocal site cookie and pass the user along; otherwise, you generate an authenticationrequest and forward the user to the authentication server, passing in the current URL sothe user can be returned to the right place when authentication is complete

signon.phpon the authentication server is similar to the login page you put togetherearlier:

<?php require_once ‘ Cookie.inc ’ ; require_once ‘ SingleSignOn.inc ’ ;

$name = $_POST[ ‘ name ’ ];

$password = $_POST[ ‘ password ’ ];

$request = $_REQUEST[ ‘ request ’ ];

$cookie = new Cookie();

} catch (AuthException $e) {

?>

<html>

<title>SingleSignOn Sign-In</title>

<body>

<form name=signon method=post>

Username: <input type= ” text ” name= ” name ” ><br>

Password: <input type= ” password ” name= ” name ” ><br>

<input type= ” hidden ” name= ” auth_request ” value= ” <?= $_REQUEST[ ‘ request ’ ] ?>

<input type=submit name=submitted value= ” Login ” >

}

?>

Let’s examine the logic of the main try{}block First, you process the authenticationrequest If this is invalid, the request was not generated by a known client of yours; soyou bail immediately with SignOnException.This sends the user a “403 Forbidden”

message.Then you attempt to read in a cookie for the authentication server If this cookie is set, you have seen this user before, so you will look up by the user by user ID(incheck_credentialsFromCookie) and, assuming that the user is authenticated for thenew requesting domain, return the user from whence he or she came with a validauthentication response If that fails (either because the user has no cookie or because ithas expired), you fall back to the login form

The only thing left to do is implement the server-side authentication functions Asbefore, these are completely drop-in components and could be supplanted with LDAP,password, or any other authentication back end.You can stick with MySQL and imple-ment the pair of functions as follows:

class CentralizedAuthentication { function check_credentials($name, $password, $client) {

$dbh = new DB_Mysql_Prod();

$cur = $dbh->prepare( “

SELECT userid FROM ss_users WHERE name = :1 AND password = :2

AND client = :3 ” )->execute($name, md5($password), $client);

$row = $cur->fetch_assoc();

if($row) {

$userid = $row[ ‘ userid ’ ];

} else { throw new SignonException( “ user is not authorized ” );

} return $userid;

$row = $cur->fetch_assoc();

if(!$row) { throw new SignonException( “ user is not authorized ” );

} } }

So you now have developed an entire working single signon system Congratulations! Asco-registrations, business mergers, and other cross-overs become more prevalent on theWeb, the ability to seamlessy authenticate users across diverse properties is increasinglyimportant

Further Reading

You can find a good introduction to using HTTP Basic Authentication in PHP in Luke

Welling and Laura Thomson’s PHP and MySQL Web Development.The standard for Basic

Authentication is set in RFC 2617 (www.ietf.org/rfc/rfc2617.txt)

The explanation of using cookies in the PHP online manual is quite thorough, but ifyou have unanswered questions, you can check out RFC 2109

(www.ietf.org/rfc/rfc2109.txt) and the original Netscape cookie specification(http://wp.netscape.com/newsref/std/cookie_spec.html)

No programmer’s library is complete without a copy of Bruce Schneier’s Applied Cryptography, which is widely regarded as the bible of applied cryptography It is incredi-

bly comprehensive and offers an in-depth technical discussion of all major ciphers His

later book Secrets and Lies: Digital Security in a Networked World discusses technical and

nontechnical flaws in modern digital security systems

An open-source single signon infrastructure named pubcookie, developed at theUniversity of Washington, is available at www.washington.edu/pubcookie.The singlesignon system discussed in this chapter is an amalgam of pubcookieand the MicrosoftPassport protocol

An interesting discussion of some risks in single signon systems is Avi Rubin andDavid Kormann’s white paper “Risks of the Passport Single Signon Protocol,” available

athttp://avirubin.com/passport.htm

Session Handling

INCHAPTER13, “USERAUTHENTICATION ANDSESSIONSecurity,” we discussed ticating user sessions In addition to being able to determine that a sequence of requestsare simply coming from the same user, you very often want to maintain state informa-tion for a user between requests Some applications, such as shopping carts and games,require state in order to function at all, but these are just a subset of the expanse ofapplications that use state

authen-Handling state in an application can be a challenge, largely due to the mass of data it

is possible to accumulate If I have a shopping cart application, I need for users to be able

to put objects into the cart and track the status of that cart throughout their entire sion PHP offers no data persistence between requests, so you need to tuck this dataaway someplace where you can access it after the current request is complete

ses-There are a number of ways to track state.You can use cookies, query string ing, DBM-based session caches, RDBMS-backed caches, application server–based caches,PHP’s internal session tools, or something developed in house.With this daunting array

mung-of possible choices, you need a strategy for categorizing your techniques.You can cate session-management techniques into two categories, depending on whether youstore the bulk of the data client side or server side:

bifur-n Client-side sessions—Client-side sessions encompass techniques that require all

or most of the session-state data to be passed between the client and server onevery request Client-side sessions may seem rather low-tech, and they are some-

times called heavyweight in reference to the amount of client/server data

transmis-sion required Heavyweight sestransmis-sions excel where the amount of state data thatneeds to be maintained is small.They require little to no back-end support (Theyhave no backing store.) Although they are heavyweight in terms of content trans-mitted, they are very database/back-end efficient.This also means that they fit withlittle modification into a distributed system

n Server-side sessions—Server-side sessions are techniques that involve littleclient/server data transfer.These techniques typically involve assigning an ID to a

session and then simply transmitting that ID On the server side, state is managed

in some sort of session cache (typically in a database or file-based handler), and thesession ID is used to associate a particular request with its set of state information.Some server-side session techniques do not extend easily to run in a distributedarchitecture

We have looked at many session-caching mechanisms in the previous chapters, cachingvarious portions of a client’s session to mete out performance gains.The principal differ-ence between session caching as we have seen it before and session state is that sessioncaching takes data that is already available in a slow fashion and makes it available in afaster, more convenient, format Session state is information that is not available in anyother format.You need the session state for an application to perform correctly

Client-Side Sessions

When you visit the doctor, the doctor needs to have access to your medical history toeffectively treat you One way to accomplish this is to carry your medical history withyou and present it to your doctor at the beginning of your appointment.This methodguarantees that the doctor always has your most current medical records because there is

a single copy and you possess it Although this is no longer common practice in theUnited States, recent advances in storage technology have advocated giving each person

a smart card with his or her complete medical history on it.These are akin to our side sessions because the user carries with him or her all the information needed toknow about the person It eliminates the need for a centralized data store

client-The alternative is to leave medical data managed at the doctor’s office or HMO (as iscommon in the United States now).This is akin to server-side sessions, in which a usercarries only an identification card, and his or her records are looked up based on theuser’s Social Security number or another identifier

This analogy highlights some of the vulnerabilities of client-side sessions:

n There is a potential for unauthorized inspection/tampering

n Client-side sessions are difficult to transport

n There is a potential for loss

Client-side sessions get a bad rap Developers often tend to overengineer solutions, ing application servers and database-intensive session management techniques becausethey seem “more enterprise.”There is also a trend among large-scale software design afi-cionados to advance server-side managed session caches ahead of heavyweight sessions.The reasoning usually follows the line that a server-based cache retains more of the stateinformation in a place that is accessible to the application and is more easily extensible

utiliz-to include additional session information

Implementing Sessions via Cookies

In Chapter 13, cookies were an ideal solution for passing session authentication mation Cookies also provide an excellent means for passing larger amounts of sessiondata as well

infor-The standard example used to demonstrate sessions is to count the number of times auser has accessed a given page:

You have visited this page <?= $MY_SESSION[ ‘ count ’ ] ?> times.

This example uses a cookie name session_cookieto store the entire state of the

$MY_SESSIONarray, which here is the visit count stored via the key count.setcookie()

automatically encodes its arguments with urlencode(), so the cookie you get from thispage looks like this:

Set-Cookie: session_cookie=a%3A1%3A%7Bs%3A5%3A%22count%22%3Bi%3A1%3B%7D;

expires=Mon, 03-Mar-2003 07:07:19 GMT

If you decode the data portion of the cookie, you get this:

a:1:{s:5: ” count ” ;i:1;}

This is (exactly as you would expect), the serialization of this:

$MY_SESSION = array( ‘ count ’ => 1);

Escaped Data in Cookies

By default PHP runs the equivalent of addslashes() on all data received via the COOKIE, POST, or GET variables This is a security measure to help clean user-submitted data Because almost all serialized variables have quotes in them, you need to run stripslashes() on

$_COOKIE[ ‘ session_data ’ ] before you deserialize it If you are comfortable with manually cleaning all your user input and know what you are doing, you can remove this quoting of input data by setting magic_quotes_gpc = Off in your php.ini file.

It would be trivial for a user to alter his or her own cookie to change any of these ues In this example, that would serve no purpose; but in most applications you do not

val-want a user to be able to alter his or her own state.Thus, you should always encrypt

ses-sion data when you use client-side sesses-sions.The encryption functions from Chapter 13will work fine for this purpose:

<?php // Encryption.inc class Encryption {

static $cypher = ‘ blowfish ’ ; static $mode = ‘ cfb ’ ; static $key = ‘ choose a better key ’ ; public function encrypt($plaintext) {

$td = mcrypt_module_open (self::$cypher, ‘’ , self::$mode, ‘’ );

$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);

mcrypt_generic_init ($td, self::$key, $iv);

$crypttext = mcrypt_generic ($td, $plaintext);

mcrypt_generic_deinit ($td);

return $iv.$crypttext;

} public function decrypt($crypttext) {

$td = mcrypt_module_open (self::$cypher, ‘’ , self::$mode, ‘’ );

$ivsize = mcrypt_enc_get_iv_size($td);

$iv = substr($crypttext, 0, $ivsize);

$crypttext = substr($crypttext, $ivsize);

$plaintext = “” ;

if ( $iv ) { mcrypt_generic_init ($td, self::$key, $iv);

$plaintext = mdecrypt_generic ($td, $crypttext);

mcrypt_generic_deinit ($td);

} return $plaintext;

} }

?>

The page needs a simple rewrite to encrypt the serialized data before it is sent via cookie:

<?php include_once ‘ Encryption.inc ’ ;

$MY_SESSION = unserialize(

stripslashes(

Encryption::decrypt($_COOKIE[ ‘ session_cookie ’ ]) )