you need to treat the session as a possible security
hole. Session security is necessary to create and
implement a session. If someone is listening in or
snooping on a network, it's possible that he can
intercept a session ID and use it to look like he
is someone else. It's also possible to access session
data from the local filesystem on multiuser systems
such as ISP hosting machines.
Session hijacking is when someone accesses either
a client's cookie or session ID, and then attempts
to use this data. Session fixation is attempting to set
your own session ID. Session fixation and hijacking
are easy to combat. We'll make use of the super global
variables for the client's IP address and browser
type to keep things secure.
<?php
session_start();
$user_check = md5($_SERVER['HTTP_USER_AGENT'] .
$_SERVER['REMOTE_ADDR']);
if (empty($_SESSION['user_data'])) {
session_regenerate_id();
echo ("New session, saving user_check.");
$_SESSION['user_data'] = $user_check;
}
if (strcmp($_SESSION['user_data'], $user_check) !== 0) {
session_regenerate_id();
echo ("Warning, you must reenter your session.");
$_SESSION = array();
$_SESSION['user_data'] = $user_check;
}
else {
echo ("Connection verified!");
}
?>
When a browser first requests the page,a session is
started. In that session, we stored the encoded
combination of the IP address and browser type.
That way, when the user returns to this page, we
can compare the value stored in the session versus
a fresh computation of the IP address and browser
type. If the two don't match, we potentially
have a hijacker, so we pick a new ID and clear
any saved data for that session. That way, the
hijacker cannot retrieve any of the private
information stored in the session. This doesn't
cause a problem for legitimate users, because
they aren't going to change browser or IP
addresses in the middle of a session with
your web site.
You know that trusting data from a user isn't a
great idea. But what exactly do you consider
to be user data versus system data that you trust?
GET
Data from GET operations is inherently user
data since it usually comes from form submissions.
POST
Data from POST operations is inherently
data since it usually comes from form submissions.
Cookies
Cookies may seem like they could be trusted
since they are automatically sent, but in reality,
since they are stored on the client's computer,
they could be intentionally altered. Therefore,
they're considered user data.
Session data
Session data can be trusted as long as the session
value is set based on validated data. If it's set
to a user-supplied value without validation,
it's not trustworthy.
User input should be checked and escaped properly.
Data that's bound for the database must have all
special characters such as single and double
quotes escaped.
