if ( /* Successfully changed pass */ ) {
    redirect( "Your new password is updated", "/page/where/success/goes.php" );
} else {
    redirect( "Your old password is invalid", "/page/to/try/again.php" );
}

Then of course you need the code from above to display the messages on both “/page/where/success/goes.php” and “/page/to/try/again.php”:

if (isset($_GET['message']) && isset($_SESSION[$_GET['message']])) {
	echo $_SESSION[$_GET['message']];
	unset($_SESSION[$_GET['message']]);
}

thanks .
Best regards.

Session poisoning (also referred to as “Session data pollution” and “Session modification”) is to exploit insufficient input validation in server applications which copies user input into session variables.

I’m often guilty of forgetting some of the things that can cause these kinds of problems. Chalk it up to being spoiled. I work with custom written software (mine) on dedicated Rackspace servers. However, there are a few ways that you can cause session poisoning.

First, you can insufficiently validate content that you store in it. To fix this, simply be careful about what you put in it, making sure it is what you mean to put there. Don’t assume a user put a number into the “total cost” field. Assume your users are malicious.

Secondly, you could have scripts or applications that use overlapping session variables. I see this as a worse possibility because “joe no coder” could download and install two conflicting scripts without even knowing it. To solve this, check out the applications you are using. If you can’t understand the code, at LEAST do some serious research.

Lastly, you could have a poorly configured shared server. Again, this is dangerous because people often don’t have control over this. Again, however, research is your friend. Please like Web Hosting Talk often have hundreds of reviews on hosts.

Jem: this isn’t aimed at you. This is aimed at filling in the gaps in the article above, for the users that need it.

“However, if you simply don’t put bad data in, you won’t get bad data out.” – obviously only an idiot do that, but that doesn’t cover the risks of sessions on badly configured shared hosting coupled with possibility of session poisoning (I only realised it had it’s own term last night, hehe): http://en.wikipedia.org/wiki/Session_poisoning

A shared host user manipulates the session and then calls it using using $_GET? Sounds perfectly feasible to me.

Call me paranoid but I would say ALWAYS sanitise, rather than simply “when in doubt”. Better safe than sorry, no?